From: | Jan Wieck <JanWieck(at)Yahoo(dot)com> |
---|---|
To: | "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com> |
Cc: | Liam Lesboch <liamlesboch(at)hotmail(dot)com>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Replication options? |
Date: | 2004-09-25 14:01:08 |
Message-ID: | 41557A24.2010703@Yahoo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
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. #
#================================================== JanWieck(at)Yahoo(dot)com #
From | Date | Subject | |
---|---|---|---|
Next Message | Kundham Saare | 2004-09-25 14:16:19 | figuring out if there was a transaction in this connection already |
Previous Message | Wayne Unruh | 2004-09-25 05:32:01 |