On 8/12/2004 12:02 PM, Joshua D. Drake wrote:
To make a transaction durable, the changes first have to be recorded in PostgreSQL's crash recovery WAL. Only after that data is flushed to the disk it can be assumed that the transaction will be redone in the case of an immediately following crash. If a replication system now logs the commit event before the WAL operation happens, it is possible that the transaction does not commit on the master due to a crash, but it will be replayed and committed on the slaves. On the other side if the replication logging of the commit is done after the WAL operation, it must be assured that WAL replay during crash recovery also causes replication log journal to be recovered or repeated. In short, the replication log must be covered by the same redo mechanism the crash recovery system uses.
This I will have to verify with our programmers as to exactly "when" the replication occurs.
Joshua,
you never followed up to this one.
Jan
-- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== [EMAIL PROTECTED] #
---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
