Date: Tue, 18 Aug 2020 13:17:40 -0400
From: Bruce Momjian <bruce@momjian.us>
To: Kasper Kondzielski <kghost0@gmail.com>
Cc: pgsql-docs@lists.postgresql.org, jaroslaw.kijanowski@softwaremill.com
Subject: Re: Request for further clarification on synchronous_commit
Message-ID: <20200818171740.GE27231@momjian.us>
References: <159741195522.14321.13812604195366728976@wrigleys.postgresql.org>
 <20200817174727.GA28474@momjian.us>
 <CAFv2VPRPmoqpVPTR64jqebQZ6zOzeTCR4xN9c6zXhvaCc4nnNg@mail.gmail.com>
 <20200818145851.GB27231@momjian.us>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200818145851.GB27231@momjian.us>
User-Agent: Mutt/1.10.1 (2018-07-13)
Precedence: bulk

On Tue, Aug 18, 2020 at 10:58:51AM -0400, Bruce Momjian wrote:
> Un, 'on' does _not_ apply the WAL data, and remote_apply does do remote
> fsync.  If you want to go in order of severity, with the most severe
> first, it is:
> 
> 	remote_apply
> 	on
> 	remote_write
> 	local
> 
> This is seen in the C enum ordering for synchronous_commit, but in
> reverse order:
> 
> 	typedef enum
> 	{
> 	    SYNCHRONOUS_COMMIT_OFF,     /* asynchronous commit */
> 	    SYNCHRONOUS_COMMIT_LOCAL_FLUSH, /* wait for local flush only */
> 	    SYNCHRONOUS_COMMIT_REMOTE_WRITE,    /* wait for local flush and remote
> 	                                         * write */
> 	    SYNCHRONOUS_COMMIT_REMOTE_FLUSH,    /* wait for local and remote flush */
> 	    SYNCHRONOUS_COMMIT_REMOTE_APPLY /* wait for local flush and remote apply */
> 	}           SyncCommitLevel;

Also, there is some logic to say that the postgresql.conf
synchronous_commit options list should be reordered from:

	#synchronous_commit = on                # synchronization level;
	                                        # off, local, remote_write, remote_apply, or on

to

	#synchronous_commit = on                # synchronization level;
	                                        # off, local, remote_write, on, or remote_apply

I think we should backpatch the doc changes, but maybe not the
postgresql.conf one --- I am not sure.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

  The usefulness of a cup is in its emptiness, Bruce Lee