On Fri, Aug 19, 2016 at 7:32 PM, Masahiko Sawada <sawada.mshk@gmail.com> wrote:
> On Fri, Aug 19, 2016 at 5:25 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>> On Thu, Aug 18, 2016 at 12:22 AM, Thomas Munro
>> <thomas.munro@enterprisedb.com> wrote:
>>> To do something about the confusion I keep seeing about what exactly
>>> "on" means, I've often wished we had "remote_flush". But it's not
>>> obvious how the backwards compatibility could work, ie how to keep the
>>> people happy who use "local" vs "on" to control syncrep, and also the
>>> people who use "off" vs "on" to control asynchronous commit on
>>> single-node systems. Is there any sensible way to do that, or is it
>>> not broken and I should pipe down, or is it just far too entrenched
>>> and never going to change?
>>
>> I don't see why we can't add "remote_flush" as a synonym for "on". Do
>> you have something else in mind?
>>
>
> +1 for adding "remote_flush" as a synonym for "on".
> It doesn't break backward compatibility.
Right, we could just add it to guc.c after "on", so that you can "SET
synchronous_commit TO remote_flush", but then "SHOW
synchronous_commit" returns "on".
The problem I was thinking about was this: if you add "remote_flush"
before "on" in guc.c, then "SHOW ..." will return "remote_flush",
which would be really helpful for users trying to understand what
syncrep is actually doing; but it would probably confuse single node
users and async replication users.
--
Thomas Munro
http://www.enterprisedb.com
