Viewing entries tagged with postgresql. Return to full view.

Monitoring PostgreSQL on Win32

A very common question from Win32 users is how to monitor Postgres the same way you can do with ps on Unix. There's a simple trick to it - don't use Task Manager, use Process Explorer from Sysinternals. So why is this. For comparision, here is a snapshot of my laptop with PostgreSQL running, and just a single client connection:

Task Manager screenshot

The same processes, as seen from Process Explorer:

Process Explorer screenshot

The most obvious difference - you can now see the process tree. You will see pg_ctl that is the service manager, that it started the postmaster, and that which subprocesses the postmaster started. You will also see the only second level postgres.exe, which is part of the stats system.

You will also notice in the Handle list, that there is an Event named pgident: .... This event contains the information you would find in the ps output on Unix and identifies the individual PostgreSQL process.

So - simply using a different tool gives you a lot more information. For 8.2 there will be some additional win32 management stuff, but more aobut that somewhere else.

Running as admin on win32 - take 2

My first patch missed out on the fact that while being able to run as admin is nice, it doesn't really help much if you can't initdb first. Because you need a database to run...

Extra patch now in the archives.

Linuxforum Copenhagen

Seems I completely forgot to post about this, but better late than never...

This year I'll be delivering a talk at Linuxforum Copenhagen. I'll be talking about some of the unique features in PostgreSQL, which means a lot about extensibility and such things. If you're around, come over and say hi!

(There's also plenty of other interesting talks there, and several speakers that are bound to be more interesting than me :-))

Running PostgreSQL as admin on Win32

Being able to run PostgreSQL from an accoun that is a local administrator is a much requested feature. There are times when this makes sense - say when you're test-running things from your own account, and you haven't yet taken the step to use a non-admin account. There are other cases when it doesn't, such as when you're creating a new account for the service anyway - there's just no point in making it an administrator then.

PostgreSQL on Unix has a check that prevents it from starting from the root account, and the same check exists on Windows in the form of checking for membership in Administrators or Power Users. This is a good thing, because it keeps the attack surface on the system way down. There are no plans to change this.

However, there is now a patch available (that will hopefully make it into 8.2, but we don't know that yet. It's been pending on -patches since jan 14th, but there are plenty of patches that have been waiting longer than that) that will let you start PostgreSQL from an adminstrative account. The code (which lives in pg_ctl) will then create and use what's known as a restricted token to launch the backend. This token will explicitly disable the Administrators and Power Users groups, as well as a whole lot of privileges that may be on by default. There is absolutely no way for anything executing in the database context (such as a stored procedure, or code injected through a security bug somewhere) to gain back these privileges. Since we take out the privileges as well, this actually makes the system slightly more secure than before.

The patch is available here, if you need it now. Should apply cleanly to 8.1 (and should work in 8.0, but may not apply cleanly). It only works on Windows 2000 and up, not NT4. But relly, you shouldn't be using NT4 any longer, for a lot of other reasons more important than this.

As a bonus, this patch wraps the database in a job object (when available, and will only work when running as a service) which makes it possible to do performance monitoring on the group of processes - such as total CPU used by all backends. Just use Performance Monitor, open up job objects, and it should list the PostgreSQL job object if it's running.

Hacking on pgAdmin

This weekend I finally took some time to dive into pgAdmin hacking. Previously, I've just nagged at Dave to get issues fixed (those few there were), but that doesn't work forever :-)

Turns out it was a lot easier than I thought. At least, that's what I think now. I've sent in several patches to the guys, and I guess I'll know if it was actually easy once I hear back from them. I might get them all back with a "yuck, this is ugly code" or something. But it does appear to at least work, which is a good first step.

In summary I have to say that it was really easy to understand the layout of the system in pgAdmin. Even though it has been many years since I did any serious C++ing, and I have never done any wx before...

The things I've worked on so far are:

  • Couple of tiny patches for building with VS2003 and for the unicode radiobuttons on the export screen
  • Ability to select all rows in the query output window, for copying, with a single keypress (Ctrl-A)
  • Ability to control quoting and separation when copying from the query results to the clipboard
  • Ability to auto-connect to a database and open a query window on startup using commandline parameters
  • Simple cut at autocompletion ("tab completion" / "intellisense" / whatever you might want to call it) for the SQL editor

Not bad for a first weekend, I think. Assuming, that is, it's actually accepted in the end...

Wow for contrib/intarray

In my ongoing quest to migrate some stuff from MSSQL to PostgreSQL, I've done my first implementation using contrib/intarray. And all I can say in this case is wow. It took some query times from 3+ seconds down to 0.4 milliseconds!! (Granted, that is on a faster machine as well - but not that much faster. And no longer dedicated. And the new machine actually has less memory than the old one).

Now, the old design was pretty darn bad. It basically had a varchar field that held a lot of numbers in the format "4,6,7,9,15". The objective was to find which rows contained say the number 9. The only way to do that in MSSQL is, AFAIK, to do a WHERE field LIKE '%259,%25', which is obviously dead slow.

For PostgreSQL, with the data stored in an intarray instead, the query is WHERE field @ '{9}'. You can even create a GIST index on it, for even faster lookups. And it's even more correct (the previous one will fail if the list has for example 19 in it. It had to be special-cased every time).

Finally, it makes it a lot easier to match for multiple values. Such as WHERE field @ '{9,14}'. For every step, the MSSQL solution just gets uglier and uglier, whereas PostgreSQL is nice and beautiful :-)

So. Arrays can be a bit of a hurdle to get into, and it will tie you down to PostgreSQL, but if you're doing something that deals with arrays or lists of integer, you should definitly check out contrib/intarray. Once again, a great job by Oleg and Teodor.

Small things making a big difference

I ported a fairly small webapp from Microsoft SQL Server to PostgreSQL today. Fairly small, but it still went pretty darn fast - took me just about an hour!

One thing that helped a lot compared to previous times I've done this is the new lastval() function in version 8.1. It takes away having to rewrite all those pieces of code that rely on the @@IDENTITY variable or SCOPE_IDENTITY() function in MSSQL. Thank you Dennis!

Apart from that there were two small things to do - get rid of the datediff() calls (and replace them with much much nicer PostgreSQL equivalents) and change JOINs to FROM on multi-table updates. Finally, I replaced the Full Text Indexes with tsearch2. Using the snowball stemmer in Swedish that also gives a lot better result than the old one, which was a nice bonus :-)

Planet upgraded

The Serendipity blog software on people.planetpostgresql.org has been upgraded to 0.9.1 for all registered blogs.

It took a lot more time and effort than it should have, because somebody seems to think it's a good idea to require the webserver to have write permissions on the php files and the directories where they live in order to do an upgrade, which is obviously a horrible idea from any kind of security perspective. It also had some bad conflicts with the safe mode in PHP, which I still don't really know what it was - took a lot of hacking before it finally worked. I'm just hoping it's a long time until the next major upgrade...

For now - enjoy your new version!

Japan Summary

Ok, so better late than never. Or hey, at least it's late. But since Dave beat me to it anyway, I got kind of sidetracked. So to make it easy, start by reading Daves post, and I won't repeat, but just add a couple of quick notes instead.

  • Plane from London to Tokyo passes almost directly over my house. About 7 hours later! Kind of feels like a waste of time, but the tickets from London were 1/3rd the price of going over Copenhagen, and Finnair through Helsinki didn't have many departures for Tokyo at all.
  • Andreas brought a Japanese to German dictionary. He still refused to translate everything for us. Can't see why.
  • Italian food in Japan is not necessarily what you'd get in Italy. But it was good...
  • Seems what we get for Japanese food here in Sweden is fairly similar to what they actually give you in Japan. Not a perfect match, but cloose.
  • Bingo. Yeah. Haven't played that for many years. That may be how I managed to win. Twice. And Andreas once. (Ok, I have on idea how long it's been since he last played it). At least it's an easy game, and they held up cards so you could read the numbers if you didn't understand japanese.
  • People told me before I went that PostgreSQL is big over in Japan. Still, it was even bigger than I thought. It seems to be used in a lot of big businesses, and it's definitly not something people hide. And the JPUG - a lot of people, and a lot of work happening in that group.

So to summarise, I'll have to start repeating Dave anyway. It was a great trip, and a fantastic experience. Many thanks to Hiroshi, SKC and the JPUG. And of course also to Dave and Andreas!

Another round of pg win32 speedups

This is actually a bit old news, but I've been out of town.

About a week ago, we got a patch from Qingqing Zhou (and changed around in several different steps my me and Tom Lane) applied to PostgreSQL 8.1 that changes the way win32 polls for the "fake signals" used to emulate Unix behaviour and eliminates a kernel call in a very active codepath. The end result of this: Very nice speedups on Windows. In some isolated test-cases up to 40%25!!! In general cases, it's going to be much less than that of course, but it is still a significan speedup. It appears especially efficient in scenarios with lots of concurrent access, bringing win32 performance much closer to what we have on Linux.

Way to go Qingqing, and thanks also to Merlin and Andrew for quick testing work.

My own update from the Japan trip coming up in a bit...

Conferences

I speak at and organize conferences around Open Source in general and PostgreSQL in particular.

Upcoming

Postgres Open 2019
Sep 11-13, 2019
Orlando, FL, USA
PGConf.EU 2019
Oct 15-18, 2019
Milan, Italy

Past

Postgres London 2019
Jul 2-3, 2019
London, UK
PGCon 2019
May 27-31, 2019
Ottawa, Canada
PGDay.IT 2019
May 17, 2019
Bologna, Italy
PGConf.DE 2019
May 10, 2019
Leipzig, Germany
FOSS North 2019
Apr 8-9, 2019
Gothenburg, Sweden
More past conferences