On Mon, Jun 22, 2009 at 8:59 PM, Craig
Ringer<craig@postnewspapers.com.au> 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.