| |||||||||||||||||||
PostgreSQL 9.0 released
PostgreSQL 9.0 is here! The PostgreSQL Global Development Group announces the availability of our most eagerly awaited release. PostgreSQL 9.0 includes built-in, binary replication, and over a dozen other major features which will appeal to everyone from web developers to database hackers. 9.0 includes more major features than any release before it, including: * Hot standby * Streaming replication * In-place upgrades * 64-bit Windows builds * Easy mass permissions management * Anonymous blocks and named parameter calls for stored procedures * New windowing functions and ordered aggregates ... and many more. For details on the over 200 additions and improvements in this version, developed by over a hundred contributors, please see the release notes. "These kinds of feature additions continue to make a strong case for why mission-critical technology tasks can continue to depend on the power, flexibility and robustness of PostgreSQL," said Afilias CTO Ram Mohan. More information on PostgreSQL 9.0: * Release notes http://www.postgresql.org/docs/9.0/static/release-9-0 * Presskit http://www.postgresql.org/about/press/presskit90 * Guide to 9.0: http://wiki.postgresql.org/wiki/What's_new_in_PostgreSQL_9.0 Download 9.0 now: * Main download page: http://www.postgresql.org/download * Source code: http://www.postgresql.org/ftp/source/v9.0.0 * Binary packages: http://www.postgresql.org/ftp/binary/v9.0.0 * One-click installer, including Windows packages: http://www.enterprisedb.com/products/pgdownload.do ---------------------------(end of broadcast)--------------------------- -To unsubscribe from this list, send an email to: pgsql-announce-unsubscribe@postgresql.org (Log in to post comments)
PostgreSQL 9.0 released Posted Sep 20, 2010 16:49 UTC (Mon) by malefic (subscriber, #37306) [Link]
Kudos to PostgreSQL developers for a marvellous job!
PostgreSQL 9.0 released Posted Sep 20, 2010 17:13 UTC (Mon) by nix (subscriber, #2304) [Link]
Agreed, this release looks lovely. Not a single change I could disagree with (unlike some past releases, when various changes had me grumbling). I'm looking forward to installing it (and have proved myself a total geek thereby).
PostgreSQL 9.0 released Posted Sep 20, 2010 18:11 UTC (Mon) by intgr (subscriber, #39733) [Link]
Curious, what past changes have made you grumble? I don't remember anything that made matters worse. (Maybe the 8.4 FSM changes reduced performance by a few percent, but the tradeoffs are very much worth it IMO)
PostgreSQL 9.0 released Posted Sep 20, 2010 20:16 UTC (Mon) by nix (subscriber, #2304) [Link]
I was using backslashed string escapes heavily. Lots of source code changes for the sake of compatibility with a SQL standard that my source trees largely didn't care about (too much use of PostgreSQL-specific features).
PostgreSQL 9.0 released Posted Sep 20, 2010 21:16 UTC (Mon) by robert_s (subscriber, #42402) [Link]
In OpenStreetMap circles it is generally recommended to stick with 8.3 for osm2pgsql/mapnik tasks, because of significant performance regressions for that particular workload.
PostgreSQL 9.0 released Posted Sep 21, 2010 16:54 UTC (Tue) by intgr (subscriber, #39733) [Link]
Are you referring to the STRICT SQL function inlining problem? It was fixed 3 months ago in PostGIS.
http://trac.osgeo.org/postgis/ticket/536
PostgreSQL 9.0 released Posted Sep 20, 2010 17:29 UTC (Mon) by flewellyn (subscriber, #5047) [Link]
Where I work we have been waiting eagerly for this release. As soon as we have had time to assess stability and possible compatibility issues, we're certain to upgrade.
The streaming replication and hot standby features, in particular, are the reason we are so interested.
PostgreSQL 9.0 released Posted Sep 20, 2010 18:01 UTC (Mon) by dskoll (subscriber, #1630) [Link] I've been running 9.0-rc1 for a while and I can't wait to upgrade our production boxes to 9.0. Someone wrote Not a single change I could disagree with. I found one incredibly minor change that caused us a bit of trouble: By default, multicolumn indexes are now named after all their columns; and index expression columns are now named based on their expressions (Tom Lane) This means that databases created in 8.x may have different index names than those created in 9.0. It means our schema-updating code has to handle both cases. Nevertheless, this is a good change in the long run and worth the small bit of pain needed to modify our schema-updating code.
PostgreSQL 9.0 released Posted Sep 20, 2010 18:59 UTC (Mon) by flewellyn (subscriber, #5047) [Link]
That only applies if the name argument is omitted. Your schema-updating code can still assign names as it sees fit.
PostgreSQL 9.0 released Posted Sep 20, 2010 19:48 UTC (Mon) by dskoll (subscriber, #1630) [Link] Well, the point is that in the past, we omitted names for convenience. Now when it comes time to drop indexes that were created in the past, we need to try both versions of the name because we can't be sure which one really exists. As I said: Not really a big deal. Just something to watch out for.
How painful is the upgrade this time? Posted Sep 20, 2010 21:35 UTC (Mon) by felixfix (subscriber, #242) [Link]
I have always procrastinated upgrading major versions of my home db just because the dump-reload cycle is a pain. I remember reading that slony could be used with old and new versions to effect an upgrade, but that never seemed worth the hassle. Presumably pg_upgrade makes it easier -- but it still looks scary :-) and sure doesn't look like fewer steps than a dump-reload. But it might take less disk space, and might be faster.
Has anyone used this?
How painful is the upgrade this time? Posted Sep 21, 2010 2:23 UTC (Tue) by chotchki (guest, #70236) [Link]
I have been doing an automated pg_dumpall -> psql restore between our 8.4 database and 9.0rc1/9.0 every night with zero issues if that helps.
How painful is the upgrade this time? Posted Sep 21, 2010 12:11 UTC (Tue) by nix (subscriber, #2304) [Link]
Downside: you have to be able to install both server versions at once, and both sets of datafiles. Not likely to be catastrophic, but not a requirement of dump/reload, so possibly disruptive.
How painful is the upgrade this time? Posted Sep 21, 2010 12:57 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]
Stop the database, make a copy (cp -a) of its files, then start DB and do an in-place update. I found out that it's the fastest way.
How painful is the upgrade this time? Posted Sep 21, 2010 14:19 UTC (Tue) by felixfix (subscriber, #242) [Link]
I didn't realize you could do an in-place upgrade.
We used to use postgres at work, but a customer demanded, and paid for, that O*** database, the one which thinks empty strings are NULL. So my exposure has been limited to my puny home db, which logs weather stats, miscellaneous stuff like that, and I have not really kept up to date, but I thought I would have remembered being able to do an in-place upgrade.
How painful is the upgrade this time? Posted Sep 21, 2010 16:32 UTC (Tue) by dskoll (subscriber, #1630) [Link]
In-place upgrade is relatively new. I think it's a contrib/ module even in 9.0.0.
|
|||||||||||||||||||