On Tue, Dec 23, 2008 at 4:23 PM, Fujii Masao <masao.fujii@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