[ANNOUNCEMENT] PostgreSQL 9.0.2 (and 4 other versions)

The PostgreSQL Global Development Group today released updates for all active branches of the PostgreSQL object-relational database system, including versions 9.0.2, 8.4.6, 8.3.13, 8.2.19, 8.1.23. Database administrators are strongly encouraged to update at the next available downtime, particularly if using version 9.0, Point-In-Time Recovery or Warm Standby.

This release is the last update to PostgreSQL 8.1. Version 8.1 is now end-of-life, and users are encouraged to upgrade to a newer version as soon as possible. See our release support policy: http://wiki.postgresql.org/wiki/Postgre … ort_Policy

This release includes numerous documentation updates and 174 bugfixes, including:

  • Avoid failure when trying to report an impending transaction wraparound condition from outside a transaction. This oversight prevented recovery after transaction wraparound got too close, because database startup processing would fail, backpatched to all versions.
  • Fix recovery from base backup when the starting checkpoint WAL record is not in the same WAL segment as its redo point, backpatched to all supported versions.
  • Force default wal_sync_method to be fdatasync for Linux, backpatched to all supported versions.
  • Fix memory leak with ANALYZE and complex index expressions, backpatched to all supported versions.
  • Fix memory leak in contrib/xml2 functions, backpatched to all supported versions.
  • Fix for segfault in pgcrypto when attempting to access an undefined public key, backpatched to all supported versions.
  • Prevent inlining an SQL function with multiple OUT parameters, backpatched to all supported versions.
  • Fix bugs in WAL replay logic for GIN indexes, backpatched to 8.2.
  • Fix segfault when accept() or a call made right after accepting a connection fails when server is compiled with GSSAPI support, backpatched to 8.3.
  • Fix error handling in tempfile deletion with log_temp_files active, backpatched to 8.3.
  • Prevent slowing of of autovacuum workers because of leakage in cost parameter over life of worker, backpatched to 8.3.
  • Check for too many children before returning “okay to proceed”, backpatched to 8.4.
  • Improve performance of internal tuplestore structures for window functions, backpatched to 8.4.

The 9.0.2 update also contains several fixes for issues with features introduced or changed in version 9.0:

  • Fix low-risk potential denial of service against RADIUS login.
  • Make OFF keyword unreserved.
  • Fix bug in tracking of latest removed WAL segment in streaming replication.
  • Fix for buffer overrun in pg_upgrade.
  • Fix memory leak in autovacuum launcher.
  • Fix for race condition in transaction ID assignment and lock acquisition in hot standby.
  • Improve performance for parallel restore with many blobs.

Overall, these releases include 79 patches to 9.0, 38 patches to 8.4, 31 patches to 8.3, 25 patches to 8.2 and 21 patches to 8.1.

See the release notes for each version for a full list of changes with details: http://www.postgresql.org/docs/9.0/static/release.html

As with other minor releases, users are not required to dump and reload their database in order to apply this update release; you may simply shut down PostgreSQL and update its binaries. Users skipping more than one update may need to check the release notes for extra, post-update steps.

Download new versions now:

What is the best / Latest Version I can/should use with Servoy

Regards,

Hi Hans,

Servoy itself ships with PostgreSQL 8.4.x. I believe they will start shipping 9.0.x with Servoy 6.0.
But you don’t have to wait for this. You can start using the latest Pg version (9.0.2) right now by downloading the one-click installer.
This will then install another instance of PostgreSQL that gets launched automatically at boottime and stays running as a service/daemon unlike the one shipped with Servoy (Developer start and stops it’s Pg instance for you).
The benefit of using this installer is that when there is another update you run the new installer and 1 minute later you are back in business with an updated Pg instance.
A heads up: when you have Servoy running when you install this new Pg instance the installer will choose to use port 5433 for your new Pg instance because your Servoy Pg instance is already using 5432.
And to make sure your image media loads correctly you should use the latest JDBC driver (jdbc3 driver is sufficient). When installing this new driver in the driver directory make sure you remove the old PostgreSQL driver, there should be only 1 PostgreSQL driver in there.

So in short: PostgreSQL 9.0.2 is the latest and greatest and works fine with Servoy using the latest PostgreSQL JDBC driver.

Hope this helps.

ROCLASI:
Servoy itself ships with PostgreSQL 8.4.x. I believe they will start shipping 9.0.x with Servoy 6.0.

We are planning to upgrade for new installs in Servoy 6, yes.

Rob

I installed PostgreSQL 9.0.2 and configured Servoy to use it.
Seems to work fine.
Are there any “best practices” for the use of PostgreSQL in combination with Servoy ?

i.e. use of databases/tablespaces/users/…

Thanks,

Hi Hans,

As far as I know there are no specific best practices for PostgreSQL with Servoy other than the normal database best practices.
I.e. don’t use roles with too many privileges than it really needs in your connection settings. Just create a user that is owner of the database and is allowed to create database objects.
You can use schemas if you want. Just create a connection that points to this schema.
Tablespaces are only needed if you need to optimize your database and want to store some large tables on a different physical harddrive.

When you want to use Servoy sequences make sure you create your PK columns (with PgAdmin) as Bigint/Integer and not as Bigserial/Serial. The last one will create the column as Bigint/Integer and also create a sequence object and links that to the column. Of course if you prefer database sequences then you should use those.

Hope this helps.