From: | Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com> |
---|---|
To: | Craig Ringer <craig(at)postnewspapers(dot)com(dot)au> |
Cc: | Gerry Reno <greno(at)verizon(dot)net>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Replication |
Date: | 2009-06-23 03:12:50 |
Message-ID: | dcc563d10906222012t4592e305j48de44354a56904c@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Mon, Jun 22, 2009 at 8:59 PM, Craig
Ringer<craig(at)postnewspapers(dot)com(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Craig Ringer | 2009-06-23 03:43:55 | Re: Replication |
Previous Message | Scott Marlowe | 2009-06-23 03:04:12 | Re: Replication |