On Thu, May 10, 2012 at 1:42 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Wed, May 9, 2012 at 10:02 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
>>> Another thing I've been wondering is whether, perhaps, we ought to
>>> keep synchronous_commit tri-valued: on/local/off, and have a separate
>>> GUC for synchronous_replication_mode. It's a bit arbitrary that "on"
>>> happens to mean remote fsync rather than remote write/receive.
>>
>> You mean the way it originally was? I would agree.
>
> No. The original design for sync rep had synchronous_commit with only
> TWO values, on and off. I think the design we eventually settled on,
> with three values, was better, and I'm in favor of keeping it.
> However, there might be some virtue in separating the knob that
> controls whether we do sync rep from the knob that controls which kind
> of sync rep we do. I'm not sure.
At least there is one problem in separating the knob: a user can set
synchronous_commit to OFF and synchronous_replication_mode to ON,
which makes the transaction wait long for replication. In this setting,
because of asynchronous commit, WAL records cannot be written to the
local disk immediately, and which means that WAL records cannot be
sent immediately, so replication wait time would get long. AFAIR this is
the reason why we merged two parameters into one before.
Regards,
--
Fujii Masao
