PostgreSQL 8.0.0 goes beta
| From: | "Marc G. Fournier" <scrappy-AT-postgresql.org> | |
| To: | pgsql-announce-AT-postgresql.org | |
| Subject: | [ANNOUNCE] PostgreSQL 8.0.0 Officially Goes Beta | |
| Date: | Mon, 9 Aug 2004 21:36:52 -0300 (ADT) | |
| Cc: | pgsql-general-AT-postgresql.org |
After almost 9 months of development, the PostgreSQL Global Development Group is proud to announce that development on PostgreSQL 8.0.0 has now finished, and is ready for some serious testing. For those wondering about the 8.0.0 designation on this release, there have been several *very* large features included in this release that we felt warranted the jump. As with all of our releases, we aim to have this one as rock solid as possible, but *at least* one of the features added to this release involved such changes that may warrant a bit extra testing post-release before deploying it in production. Although the list of new features in 8.0.0 is extensive, with both SMB (Win32 Native Support) and Enterprise (Nested Transactions and Point in Time Recory) features being added, there is one thing that hasn't been included as part of the core distribution, and that is a Windows Installer, which can be found at: http://pgfoundry.org/projects/pginstaller For a complete list of changes/improvements since 7.4.0 was released, please see: http://developer.postgresql.org/beta-history.txt That said, and without further ado, Beta 1 is currently available for download on all mirrors: http://www.postgresql.org/mirrors-ftp.html And, thanks to David Fetter, the Beta is also available via BitTorrent at: http://bt.postgresql.org As with all releases, the success of this release falls in the your hands ... to go from Beta -> Release, 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 The more bugs we can find, and eliminate, during Beta, the more successful the Release will be ... On behalf of all of the developers, Happy Bug Hunting ... ---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend
Posted Aug 10, 2004 15:27 UTC (Tue)
by bdw (guest, #16047)
[Link] (8 responses)
Posted Aug 10, 2004 16:41 UTC (Tue)
by lolando (guest, #7139)
[Link] (7 responses)
(Yes, that was a bit of a troll -- I very much prefer PostgreSQL to MySQL, but I still regret this obvious lack of replication.)
Posted Aug 10, 2004 16:53 UTC (Tue)
by danpb (subscriber, #4831)
[Link] (4 responses)
http://lwn.net/Articles/92710/
[quote]
Posted Aug 11, 2004 2:47 UTC (Wed)
by zone (guest, #3633)
[Link] (3 responses)
It's a third-party trigger based solution. It does not have access to PostgreSQL's internal data structures and therefore has very limited decision making abilities compared to real replication systems. It cannot replicate schema changes, for example, because that is something Postgres doesn't expose (nor should it). It also uses standalone daemons which can die independently of the database, and separate configuration files that can get out of sync.
In order to be competitive, Postgres needs a built-in replication system capable of replicating everything Postgres is capable of using it's native transaction and point in time facilities rather than reinventing them outside of Postgres. Replication is still a gap that Postgres needs to fill, and I'm hoping for sooner rather than later.
Posted Aug 11, 2004 12:20 UTC (Wed)
by danpb (subscriber, #4831)
[Link]
Whether its a standalone daemon or part of main PG daemon is pretty irrelevant - a forked process in the main server can just as easily die as a standalone process, with the added bonus that it could take out the entire DB rather than just the replication daemon. If a standalone replication daemon died, your monitoring software (eg Nagios, BigSister, many others) would alert production support & it could be re-started, at which point it'll seemlessly catch up to where it left off.
Separating configuration files from the main server config is actually desireable in some circumstances. For example, Slony-1 quite happily allows master & slave to be running different PG server versions (if the app in question supports it of course), so having replication config merged with main server config would actually increase admin burden in this case. The question of configuration file consistency is something that would be addressed OS-wide, not just for slony & PG. cf-engine is one possible tool, but there are a great many others.
Posted Aug 11, 2004 12:26 UTC (Wed)
by JanniCash (guest, #23933)
[Link] (1 responses)
A replication solution that is designed on purpose to support version upgrades from existing installations of PostgreSQL can hardly be embedded in the server engine. This concept fixed ties one version of the replication system to one version of the database. That gives zero flexibility to future enhancements of the replication system while maintaining backward database support.
I don't know where the idea to replicate arbitrary schema changes automatically comes from. A lot of people think this is a must have, while I think it is obsolete or even limits the usefullness of a replication solution. I have not seen many developers who need production quality replication for their prototyping- and test-system. Schema changes on production servers go through the same QA process as the application itself, so in a professional environment the Slony support for DDL scripts is absolutely sufficient.
Where the idea of "replicating everything" really starts to get annoying is when you intend to use certain replicas for special purposes. A replica that is serving search request might need a couple additional indexes that would only eat CPU and IO on all other nodes. The ability to replicate a subset of a databases objects and have additional triggered funcitonality on either the origin or a replica is entirely gone with the blind "copy all" approach.
Slony-I is trigger based, yes, but the triggers are implemented in C and have full access to the PostgreSQL backend internal structures. They do not write some external binary file but rather rely on the PostgreSQL crash recovery mechanism to ensure that what is committed will be replicated. The only other way to guarantee that for an asynchronous replication system (something utilizing 2PC isn't) would be to read the write ahead log. An approach done by an external process in the replication solution DataPropagator for IBM DB2. This program (capture) then inserts the extracted log information into capture data tables, read via select by an external process (apply) on the remote replica and applied via insert, update and delete operations to same. No arbitrary DDL support either. Would you claim that DataPropagator for IBM DB2 is not a production grade replication solution or could you point out in what respect Slony-I cannot compete with it?
Sincerely,
Posted Sep 27, 2004 3:20 UTC (Mon)
by nextdude (guest, #24999)
[Link]
How about an object-oriented persistence framework that runs on a server than needs 100% uptime? I've got an object-oriented application where the structure of existing object classes may change (occasionally) or where new object classes are added (frequently). In either scenario, I'd like a replication solution that can transparently replicate the necessary schema changes on the fly to minimize downtime with no further intervention required at the database level.
How can SLONY-I support that?
Posted Aug 10, 2004 17:22 UTC (Tue)
by bdw (guest, #16047)
[Link]
Posted Aug 11, 2004 8:00 UTC (Wed)
by neveripe (guest, #23931)
[Link]
http://gborg.postgresql.org/project/erserver/projdisplay.php
It's nice to see that PostgreSQL is starting to rival Oracle. I hope that PostgreSQL will eventually support the "grid" concept that Oralce has.PostgreSQL 8.0.0 goes beta
It'd also be nice to see PostgreSQL starting to rival MySQL. Like, by including a replication engine.PostgreSQL 8.0.0 goes beta
You must have missed the posting announcing Slony-1 replication engine thenPostgreSQL 8.0.0 goes beta
http://gborg.postgresql.org/project/slony1/news/newsfull....
The Slony-I team proudly presents the 1.0.0 release of Slony-I, the most advanced replication solution for the most advanced Open Source Database in the world. Slony-I, which functions on PostgreSQL 7.3 or better, does asynchronous master-to-multiple-slaves replication, slave promotion and failover, and helps you do PostgreSQL upgrades with extremely short downtimes.
[/quote]
Slony-I is not a production quality replication solution, and never will be.PostgreSQL 8.0.0 goes beta
It has full access to the data dictionary so can detect inconsistencies in the schemas between master & slave. For production systems, schema changes would generally be done with managed upgrade scripts, so there is minimal admin overhead running those scripts on both master & slaves. PostgreSQL 8.0.0 goes beta
Just because the main DB server process starts the replication engines thread or process doesn't make it more robust. The best example for that is MySQL reporting replication healthy because the threads do exist, while no data is replicated at all any more. PostgreSQL 8.0.0 goes beta
Jan Wieck
Slony-I lead developer
> I don't know where the idea to replicate arbitrary schema changesPostgreSQL 8.0.0 goes beta
> automatically comes from.
Oh, I understand. :) But, if you see below, there is a replication engine available for PostgreSQL. :)PostgreSQL 8.0.0 goes beta
There is production former commercial replication system:PostgreSQL 8.0.0 goes beta