Re: Sync Rep: First Thoughts on Code

Hi,

On Tue, Dec 16, 2008 at 7:21 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>
> On Tue, 2008-12-16 at 12:36 +0900, Fujii Masao wrote:
>
>> > 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?
>
> No, we've been through that loop already a few months back:
> Transaction-controlled robustness.
>
> It should be up to the client on the primary to decide how much waiting
> they would like to perform in order to provide a guarantee. A change of
> setting on the standby should not be allowed to alter the performance or
> durability on the primary.

OK. I will extend synchronous_replication, make walsender send XLOG
with synchronization mode flag and make walreceiver perform according
to the flag.

>
> My perspective is that synchronous_replication specifies how long to
> wait. Current settings are "off" (don't wait) or "on" (meaning wait
> until point #3). So I think we should change this to a list of options
> to allow people to more carefully select how much waiting is required.

In the latest patch, "off" keeps us waiting for replication in some
cases, e.g. forceSyncCommit = true. This is analogous to the way
synchronous_commit works. When "off" keeps us waiting for
replication, which option (#1-#6) should we choose? Should it be
user-configurable (though the parameter values are doubled)?
hardcode #3? "off" always should not keep us waiting for
replication?

Regards,

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