On Fri, Aug 19, 2016 at 7:32 PM, Masahiko Sawada <sawada.m...@gmail.com> wrote: > On Fri, Aug 19, 2016 at 5:25 AM, Robert Haas <robertmh...@gmail.com> wrote: >> On Thu, Aug 18, 2016 at 12:22 AM, Thomas Munro >> <thomas.mu...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
