Re: Sync Rep: First Thoughts on Code - Mailing list pgsql-hackers

From Fujii Masao
Subject Re: Sync Rep: First Thoughts on Code
Date
Msg-id 3f0b79eb0812151936y5d4ab129i96794a62f58e95ab@mail.gmail.com
Whole thread Raw
In response to Re: Sync Rep: First Thoughts on Code  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: Sync Rep: First Thoughts on Code  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
Hi,

Sorry for this late reply. And, thanks for the hot discussion ;)

On Tue, Dec 16, 2008 at 1:24 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
>
> Fujii-san,
>
> Just repeating this in case you lost this comment:
>
> On Mon, 2008-12-15 at 09:40 +0000, Simon Riggs wrote:
>
>> Fujii-san, please can we incorporate those two options, rather than just
>> one choice "synchronous_replication = on". They look like two commonly
>> requested options.
>
> I see the comment in line 230+ of walreceiver.c, so understand that you
> have implemented option #3 from the following list.
>
> So from my previous list
>
> 1. We sent the message to standby (A)
> 2. We received the message on standby
> 3. We wrote the WAL to the WAL file (B)
> 4. We fsync'd the WAL file (C)
> 5. We CRC checked the WAL commit record
> 6. We applied the WAL commit record
>
> Please could you also add an option #4, i.e. add the *option* to fsync
> the WAL to disk at commit time also. That requires us to add a third
> option to synchronous_replication parameter.

The above option should be configured on the primary? or standby?
The primary is suitable to vary it from transaction to transaction. On
the other hand, it should be configured on the standby in order to
choose it for every standby (in the future).

I prefer the latter, and thought that it should be added into recovery.conf.
I mean, synchronous_replication identifies only whether commit waits for
replication (if the name is confusing, I would rename it). The above
options (#1-#6) are chosen in recovery.conf. What is your opion?

>> #6 is an additional synchronization step in Hot Standby. I would say
>> that people won't want that when they see how it performs (they probably
>> won't want #4 either for that same reason, but that is for robustness).
>
> We can jointly add option #6 once we have both sync rep and hot standby
> committed, or at a late stage of hot standby development. There's not
> much point looking at it before then.

Agreed.

Regards,

-- 
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: DROP ROLE dependency tracking ...
Next
From: Bruce Momjian
Date:
Subject: Re: Mostly Harmless: Welcoming our C++ friends