On Wed, Jun 30, 2010 at 5:36 AM, Fujii Masao <masao.fu...@gmail.com> wrote: >> Before we get too busy frobnicating this gonkulator, I'd like to see a >> little more discussion of what kind of performance people are >> expecting from sync rep. Sounds to me like the best we can expect >> here is, on every commit: (a) wait for master fsync to complete, (b) >> send message to standby, (c) wait for reply for reply from standby >> indicating that fsync is complete on standby. Even assuming that the >> network overhead is minimal, that halves the commit rate. Are the >> people who want sync rep OK with that? Is there any way to do better? > > (c) would depend on the synchronization mode the user chooses: > > #1 Wait for WAL to be received by the standby > #2 Wait for WAL to be received and flushed by the standby > #3 Wait for WAL to be received, flushed and replayed by the standby > > (a) would depend on synchronous_commit. Personally I'm interested in > disabling synchronous_commit on the master and choosing #1 as the sync > mode. Though this may be very optimistic configuration :) > > The point for performance of sync rep is to parallelize (a) and (b)+(c), > I think. If they are performed in a serial manner, the performance > overhead on the master would become high.
Right. So we to try to come up with a design that permits that, which must be robust in the face of any number of crashes on the two machines, in any order. Until we have that, we're just going around in circles. One thought that occurred to me is that if the master and standby were more tightly coupled, you could recover after a crash by making the one with the further-advanced WAL position the master, and the other one the standby. That would get around this problem, though at the cost of considerable additional complexity. But then if one of the servers comes up and can't talk to the other, you need some mechanism for preventing split-brain syndrome. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
