On Thu, May 27, 2010 at 3:21 PM, Simon Riggs <si...@2ndquadrant.com> wrote: > On Thu, 2010-05-27 at 11:28 +0900, Fujii Masao wrote: >> On Wed, May 26, 2010 at 10:20 PM, Simon Riggs <si...@2ndquadrant.com> wrote: >> > On Wed, 2010-05-26 at 18:52 +0900, Fujii Masao wrote: >> > >> >> I guess that dropping the support of #3 doesn't reduce complexity >> >> since the code of #3 is almost the same as that of #2. Like >> >> walreceiver sends the ACK after receiving the WAL in #2 case, it has >> >> only to do the same thing after the WAL flush. >> > >> > Hmm, well the code for #3 is similar also to the code for #4. So if you >> > do #2, its easy to do #2, #3 and #4 together. >> >> No. #4 requires the way of prompt communication between walreceiver and >> startup process, but #2 and #3 not. That is, in #4, walreceiver has to >> wake the startup process up as soon as it has flushed WAL. OTOH, the >> startup process has to wake walreceiver up as soon as it has replayed >> WAL, to request it to send the ACK to the master. In #2 and #3, the >> prompt communication from walreceiver to startup process, i.e., changing >> the poll loop in the startup process would also be useful for the data >> to be visible immediately on the standby. But it's not required. > > You need to pass WAL promptly on primary from backend to WALSender. > Whatever mechanism you use can also be reused symmetrically on standby > to provide #4. So not a problem.
I cannot be so optimistic since the situation differs from one process to another. >> > The comment is about whether having #3 makes sense from a user interface >> > perspective. It's easy to add options, but they must have useful >> > meaning. >> >> #3 would be useful for people wanting further robustness. In #2, >> when simultaneous power failure on the master and the standby, >> and concurrent disk crash on the master happen, transaction whose >> "success" indicator has been returned to a client might be lost. >> #3 can avoid such a critical situation. This is one of reasons that >> DRBD supports "Protocol C", I think. > > Which few people use it, or if they do its because DRBD didn't > originally support multiple standbys. Not worth emulating IMHO. If so, #3 would be useful for people who don't afford to buy more than one standby servers, too :) Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers