On Mon, Jun 22, 2009 at 8:59 PM, Craig Ringer<craig@xxxxxxxxxxxxxxxxxxxxx> wrote: > So ... it doesn't seem likely that statement-level replication would > ever get far in Pg because of nasty issues like this one. It's exactly what pg_pool does, and you can choose it if you know what you're doing. But yes, it's usually a bad fit for replication by itself. > That was my point re concurrent execution of statements. Nothing to do > with ensuring key uniqueness without inter-node synchronisation in > multi-master environments. > > Block-level master/slave synchronous replication, however, is already on > the way. (Also, Slony provides row-level master/slave replication that > seems to work well for a lot of people, though it's widely admitted to > be a bit of a pain to work with and not particularly nice.) I think it's real easy to work with, once you understand that "it's boss". I.e. you do things the slony way, or get used to recreating / resubscribing a lot of times during maintenance windows when you can run on one db. The mis-feature of no ability to drop tables caught me out. Now we don't drop tables, period. We rename and alter to get around that. Once I told the developers not to drop tables in order to change them, things got better. Really it was bad habits learned from other dbs. -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
