Date: Wed, 13 May 2020 22:40:52 -0400
From: Bruce Momjian <bruce@momjian.us>
To: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Cc: noah@leadboat.com, pgsql-hackers@postgresql.org
Subject: Re: PG 13 release notes, first draft
Message-ID: <20200514024052.GA8853@momjian.us>
References: <20200512203809.GA4666@momjian.us>
 <20200513.115633.157251733478541458.horikyota.ntt@gmail.com>
 <20200513151518.GA20111@momjian.us>
 <20200514.095141.1411370156366955955.horikyota.ntt@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200514.095141.1411370156366955955.horikyota.ntt@gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Precedence: bulk

On Thu, May 14, 2020 at 09:51:41AM +0900, Kyotaro Horiguchi wrote:
> At Wed, 13 May 2020 11:15:18 -0400, Bruce Momjian <bruce@momjian.us> wrote in 
> > On Wed, May 13, 2020 at 11:56:33AM +0900, Kyotaro Horiguchi wrote:
> It is just an more accurate (not an detailed) version of the
> previously proposed description.  If we simplify that, I choose to
> remove explanation on wal_skip_threshold.
> 
> How about this?
> 
> WAL-logging is now skipped while all kinds of bulk-insertion, then
> relations are sync'ed to disk at commit.  Previously this was done
> only for COPY operations, but the implementation had a bug that could
> cause data loss during crash recovery.

OK, I went with this text, stating WAL "generation" is skipped:

	Allow skipping of WAL for full table writes if wal_level is 'minimal'
	(Kyotaro Horiguchi)
	
	Relations larger than wal_skip_threshold will have their files
	fsync'ed rather than generating WAL.  Previously this was done
	only for COPY operations, but the implementation had a bug that
	could cause data loss during crash recovery.

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

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +