On Thu, 2005-10-13 at 17:48, Tatsuo Ishii wrote: > > On Thu, Oct 13, 2005 at 10:53:51AM -0700, Chris Travers wrote: > > > Now, what about PgPool as a multimaster sync replication solution? Sure > > > it is statement level.... But is there any reason why you cannot have > > > multiple PgPool instances running against a number of DB servers? > > > > Well, to begin with, you have a serious race condition: > > > > pgpool begins T1 on M1 and M2. > > Someone logs into M2 and does some work in T2. > > M1 completes the work of T1. > > M2 completes the work of T2. > > pgpool issues COMMIT. > > M1 replies with the COMMIT. > > M2 detects a deadlock when T2 tries to COMMIT. > > > > Now what? There's nothing to prevent this in the system, as near as > > I can see, so it's just not bullet proof enough for the cases where > > people really, really need only five minutes of down time a year. If > > you _really_ needed that, you'd be willing (and able) to pay the > > costs. Of course, we can do what we can to make those costs go down. > > :-> But they're not that low yet. > > Why pgpool should bother? pgpool supposes every transaction should go > through pgpool. Your example sounds like someone logs into M2 and tries > to shut down it. I had the same thought. Every time I've set up a system with pgpool, I've always configured the db servers on an odd port, cut it off with a firewall to anything but the pgpool machine and set it to only answer to pgpool's IP and only let users access the system through pgpool. USers accessing machines behind the scenes is a VERY bad idea. It's not a pgpool bug, is a user bug. :) ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
