Re: synchronous_commit = remote_flush

From: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: synchronous_commit = remote_flush
Date: 2016-08-19 07:32:50
Message-ID: CAD21AoAQHcF+1Y0mfBEB=7ikLOZZSthMJg6y1rpgXwYfPs3rgg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Aug 19, 2016 at 5:25 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Thu, Aug 18, 2016 at 12:22 AM, Thomas Munro
> <thomas(dot)munro(at)enterprisedb(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message konstantin knizhnik 2016-08-19 07:34:33 Logical decoding restart problems
Previous Message Thomas Munro 2016-08-19 07:07:18 Dynamic shared memory areas