On Tue, Dec 23, 2008 at 4:23 PM, Fujii Masao <masao.fu...@gmail.com> wrote: > > > But, since I cannot obtain consensus from hackers including you, > I would change my course, and forbid XLogFlush (called from other > than RecordTransactionCommit) to replicate xlog synchronously > if asynchronous replication case. >
Since synchronous/asynchronous behavior of replication is tied to a transaction (even if there is global default) , I don't understand why we should not ship the xlogs to the standby when xlogs are written on primary outside of a transaction context. This is quite same as we do with asynchronous_commit where we flush the xlog to disk at certain points irrespective of the synchronization set. > Yes, switchover is one of case example I care. Typically, I care > about restarting the failed server (original primary) after failover: > I think this is a very important requirement because it's quite unrealistic to expect that every time there is a failover, fresh backup is required for the old primary to join back the replication. > ------------- > 1. a dirty buffer page is chosen as victim of buffer replacement > 2. flush xlog up to the buffer's LSN on only primary > 3. write out the dirty buffer page > 4. primary fails > (replication up to buffer's LSN is not performed) > > The above case produces inconsistency between data on the > original primary (failed server) and xlogs on the original standby > (new primary after failover). Isn't this right? > Yes, it would create inconsistency which I don't think can be corrected without a fresh backup. Thanks, Pavan -- Pavan Deolasee EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
