Re: synchronous_commit = remote_flush - Mailing list pgsql-hackers

From Masahiko Sawada
Subject Re: synchronous_commit = remote_flush
Date
Msg-id CAD21AoAQHcF+1Y0mfBEB=7ikLOZZSthMJg6y1rpgXwYfPs3rgg@mail.gmail.com
Whole thread Raw
In response to Re: synchronous_commit = remote_flush  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: synchronous_commit = remote_flush  (Thomas Munro <thomas.munro@enterprisedb.com>)
List pgsql-hackers
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.

Regards,

--
Masahiko Sawada



pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Dynamic shared memory areas
Next
From: konstantin knizhnik
Date:
Subject: Logical decoding restart problems