PostgreSQL 8.2 EOL

PostgreSQL 8.2 has reached the end of its life. Start making your transition now.

From the release announcement ( on December 5, 2011:

This is also the last update for PostgreSQL 8.2, which is now End-Of-Life (EOL). Users of version 8.2 should plan to upgrade their PostgreSQL installations to 8.3 or later within the next couple of months. For more information, see our Release Support Policy. []

/run? /var/run? Other? Or Why You Need to Update to the Latest PostgreSQL Initscript

The PostgreSQL ebuilds and initscript are now capable of using either /run or /var/run for the default socket directory.

The ebuilds will determine which to use at build time. The logic simply being, “Does /run exist?” If it does, everything is adjusted accordingly. If not, everything is adjusted accordingly. The old initscript is incapable of using /run or any other socket directory. So, if you upgrade to the latest version of the ebuilds and fail to upgrade the initscript, you’re going to have issues if you have a /run directory.

Also, this may cause a hiccup when an application is expecting the default location to be in /var/run/postgresql rather than /run/postgresql. The proper solution is not to rebuild everything — you can if you want, but that’s time consuming — but to specify the directory to look in for the socket. Anywhere you’d specify the host you can actually specify the socket directory. Or, you should be able to if the application did it right.

Something that is more important for those who have /run or /var/run on tmpfs, the initscript now takes care of creating the directory if it’s missing. With proper permissions of course.

The next neat thing is that the initscript respects two settings it previously ignored. Well, it ignored one setting outright, and allowed you to set another in /etc/conf.d/postgresql-${SLOT} only. If you set port or socket_directory in the postgresql.conf, the initscript will now pick it up and use those settings over what’s set in /etc/conf.d/postgresql-${SLOT}.

The growing pains aren’t over just yet. Out of three machines, one machine didn’t like the new initscript. It couldn’t shutdown an existing, running server. The other two did it just fine. Same setups. Nothing fancy. Just inexplicable. It’s easy enough to shutdown the server manually, and cleanly. Issue the following substituting the path for wherever your server’s data directory actually resides.

# kill -SIGTERM $(head -n1 /var/lib/postgresql/9.1/data/

If that doesn’t do the trick, you can substitute -SIGTERM with -SIGINT as that will close client connections and rollback the transactions those clients may have been in, as that is the most common cause as to why -SIGTERM wouldn’t work.

Merry Christmas!

Updates to Init Script and More Perl Fixes for PostgreSQL

Thanks to Diego E. Pettenò (flameeyes) we’ve got some updated initscripts that are a good deal cleaner.

I did experience one inexplicable hiccup where it wouldn’t stop the server. If you run into that, just do:

kill -SIGINT $(head -n1 ${DATA_DIR}/

Where ${DATA_DIR} is the data directory for PostgreSQL server. (Usually, /var/lib/postgresql/$SLOT/data/.)

There have been a couple of fixes regarding Perl, most notably bug 378865 (

Find all the changes at the official post. (

Have fun!