PostgreSQL 8.0.0 Release Candidate 1
| From: | "Marc G. Fournier" <scrappy-AT-postgresql.org> | |
| To: | pgsql-announce-AT-postgresql.org | |
| Subject: | [ANNOUNCE] PostgreSQL 8.0.0 Release Candidate 1 | |
| Date: | Sat, 4 Dec 2004 00:18:03 -0400 (AST) | |
| Cc: | pgsql-general-AT-postgresql.org |
After 3 months of BETA testing, The PostgreSQL Global Development Group is
pleased to announce that we've locked down the source code and have now
released our first Release Candidate.
Our goal is to formally release 8.0.0 around the 15th of December, and to
ensure that we are as bug free as possible, on as many platforms as
possible, we are asking everyone that can to test and report both
successes, and failures, on the various operating systems and platforms.
For a complete list of changes/improvement since Beta 5 was released,
please see:
ftp://ftp.postgresql.org/pub/source/v8.0.0beta/ChangeLog-...
That said, Release Candidate 1 is currently available for download on all
mirrors:
http://www.postgresql.org/mirrors-ftp.html
As with all releases, the success of this release falls in the your hands
... in order to release as stable and reliable of a server as is possible,
we need as many people out there to put it through her paces as possible,
on as many platforms as possible. We urge anyone, and everyone, to
download a copy and run her through her regression tests, and report
any/all problems, and bugs, to
pgsql-bugs@postgresql.org
Once more, on behalf of all of the developers, Happy Bug Hunting ...
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
Posted Dec 6, 2004 21:47 UTC (Mon)
by TwoTimeGrime (guest, #11688)
[Link] (12 responses)
Posted Dec 6, 2004 22:39 UTC (Mon)
by jwb (guest, #15467)
[Link] (11 responses)
Of course the smart db sysadmin will be waiting to see what carnage other users report in 8.0, while solidifying his plans to move to 8.4 :)
Posted Dec 6, 2004 23:03 UTC (Mon)
by dlang (guest, #313)
[Link] (1 responses)
you don't seem to like them fixing it, but the result is poor compatability with code written for other databases. this may be fine with the MySQL team, but the Postgres team has chosen to fix the problems to improve the ability for people to migrate away from other databases.
also you can use Slony to replicate your database to another server and then during the maintinance window you just change the master from the 7.4 to the 8.0 and as a bonus it continues to maintain your 7.4 database in case you need to fail back.
now with any release with this many changes you do extensive testing before you deploy it, and this one is no different (would you dare to migrate from Oracle 8 to oracle 9 without doing something very similar to this? at the very least you would want to make a backup, and then checking the backup before you overwrite the data is a VERY good idea, and suddenly you are back to the same space and IO requirements)
Posted Dec 7, 2004 15:57 UTC (Tue)
by rst (guest, #5098)
[Link]
Interoperability is a fine goal, but interoperability with your own past releases is worth as much consideration as interoperability with anybody else. A staged transition treats both with equal respect.
Posted Dec 6, 2004 23:32 UTC (Mon)
by iabervon (subscriber, #722)
[Link] (1 responses)
I'd say it's nice of Postgres to change the major number when they break compatibility. If your 7.4 database were going to be upgradable to this version, they would have to call it 7.5 to make sense...
Posted Dec 6, 2004 23:39 UTC (Mon)
by jwb (guest, #15467)
[Link]
Posted Dec 7, 2004 14:32 UTC (Tue)
by sphealey (guest, #1028)
[Link] (6 responses)
That isn't significantly different from Oracle's upgrade procedure. I suggest that if you are running a mission-critical database you should have 3x disk space available for just such a contingency.
sPh
Posted Dec 7, 2004 15:28 UTC (Tue)
by angdraug (subscriber, #7487)
[Link] (5 responses)
Posted Dec 7, 2004 15:45 UTC (Tue)
by emkey (guest, #144)
[Link] (4 responses)
I agree though that this shouldn't be considered unusual.
Posted Dec 7, 2004 18:59 UTC (Tue)
by dlang (guest, #313)
[Link] (3 responses)
then you wipe out the old database files, upgrade the database engine and restore from your backup
this doesn't require any more disk space then your normal backup/restore requires
I agree that it would be nice if the dump/restore wasn't nessasary, but I don't see it being a critical flaw either
Posted Dec 8, 2004 0:19 UTC (Wed)
by khim (subscriber, #9252)
[Link] (2 responses)
Your insurance will cover operation disrutions from freak storm when you'll need week to restore your database. It will not cover database engine upgrade. And backup/restore cycle can easily eat few days if we are talking about terabytes. Oracle and even MySQL can live without such huge move while you are upgrading (true, you need to stop database and make some changes in system tables in both cases but bulk of your data never need to be converted in upgrade process). Yes, this is not the most important problem with PostgreSQL but it's annoying as hell: when you need to sped few days just to switch versions it's not funny - even if you can afford it.
Posted Dec 8, 2004 5:23 UTC (Wed)
by dlang (guest, #313)
[Link] (1 responses)
in addition if you do have terabytes to migrate then use Slony, it lets you replicate between different versions of postgres. once the replication catches up (however long that takes) then you have a single command to run to switch which database you use.
yes this requires multiple database servers to do this, but if you really are running a mission-critical system you should have multiple servers (and at the cost of servers and disk space nowdays it's not that expensive to add it if you need it).
Posted Dec 8, 2004 7:35 UTC (Wed)
by sbergman27 (guest, #10767)
[Link]
Straight from the MySQL documentation:
"MySQL supports several storage engines that act as handlers for different table types. MySQL storage engines include both those that handle transaction-safe tables and those that handle non-transaction-safe tables:"
For those of you who are wondering what's new in Postgres 8, here's a summary:New Features in PostgreSQL 8.0.0
http://developer.postgresql.org/beta-history.txt
Nice to see that the PostgreSQL project has maintained the tradition of impossible version migrations. Sometimes I wonder if any Pg users maintain anything larger than the most trivial databases, because to migrate to 8.0 requires the user to 1) check all code for use of LENGTH() and BIT(), the semantics of which have changed, 2) dump and reload the database, meaning the user needs to have at least enough storage to hold three copies of their database, and enough I/O bandwidth to read and write it twice during a given maintenance window.New Features in PostgreSQL 8.0.0
if a command is found to return a non-standard result what is the right answer?New Features in PostgreSQL 8.0.0
What are you supposed to do when you want to change the behavior of a widely used feature? You stage the transition -- at the very least, allow people who are relying on the old behavior to retain it with a --broken-back-compatibility switch, or the moral equivalent. (The Python community has managed several transitions like this, and goes through more stages -- in the release where the new behavior first appears, you often have to explicitly ask for it with a "from future import ..."). New Features in PostgreSQL 8.0.0
If you ever want to change database versions, you pretty much have to follow the standard and avoid any features that aren't following the standard in the version you're using. Alternatively, you can plan to keep running the same major version forever, which is probably relatively wise; if the database was satisfactory in version N before N+1 come out, it is still satisfactory in version N afterwards.New Features in PostgreSQL 8.0.0
That would be true about the version numbers, except you needed to dump and restore to upgrade from 7.3 to 7.4.New Features in PostgreSQL 8.0.0
> 2) dump and reload the database, meaning the user New Features in PostgreSQL 8.0.0
> needs to have at least enough storage to hold three
> copies of their database, and enough I/O bandwidth to
> read and write it twice during a given maintenance window.
Not to mention that if you "maintain anything larger than the most trivial databases", you're definitely doing backups, don't you?New Features in PostgreSQL 8.0.0
The backups are beside the point. If you don't have enough disk space then you can't do the conversion.New Features in PostgreSQL 8.0.0
you backup (probably as you useually do, possibly by doing a dump instead of backing up the raw disk)New Features in PostgreSQL 8.0.0
New Features in PostgreSQL 8.0.0
umm, for MySQL you have completely different table types that you need to start useing with different functionality. this is almost a case of multiple database engines in one program, hardly an easy upgrade pathNew Features in PostgreSQL 8.0.0
It's more than *almost* a case of multiple database engines in one program.New Features in PostgreSQL 8.0.0