Date: Tue, 12 May 2020 16:38:09 -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: <20200512203809.GA4666@momjian.us>
References: <20200507133834.GJ3649@momjian.us>
 <20200508042202.GA563018@rfd.leadboat.com>
 <20200512001204.GF4666@momjian.us>
 <20200512.130908.2082912530895654639.horikyota.ntt@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200512.130908.2082912530895654639.horikyota.ntt@gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Precedence: bulk

On Tue, May 12, 2020 at 01:09:08PM +0900, Kyotaro Horiguchi wrote:
> > > commit c6b9204
> > > Author:     Noah Misch <noah@leadboat.com>
> > > AuthorDate: Sat Apr 4 12:25:34 2020 -0700
> > > Commit:     Noah Misch <noah@leadboat.com>
> > > CommitDate: Sat Apr 4 12:25:34 2020 -0700
> > > 
> > >     Skip WAL for new relfilenodes, under wal_level=minimal.
> > >     
> > >     Until now, only selected bulk operations (e.g. COPY) did this.  If a
> > >     given relfilenode received both a WAL-skipping COPY and a WAL-logged
> > >     operation (e.g. INSERT), recovery could lose tuples from the COPY.  See
> > >     src/backend/access/transam/README section "Skipping WAL for New
> > >     RelFileNode" for the new coding rules.  Maintainers of table access
> > >     methods should examine that section.
> > 
> > OK, so how do we want to document this?  Do I mention in the text below
> > the WAL skipping item that this fixes a bug where a mix of simultaneous
> > COPY and INSERT into a table could lose rows during crash recovery, or
> > create a new item?
> 
> FWIW, as dicussed upthread, I suppose that the API change is not going
> to be in relnotes.
> 
> something like this?
> 
> - Fix bug of WAL-skipping optimiazation 
> 
> Previously a trasaction doing both of COPY and a WAL-logged operations
> like INSERT while wal_level=minimal can lead to loss of COPY'ed rows
> through crash recovery.  Also this fix extends the WAL-skipping
> optimiazation to all kinds of bulk insert operations.

Uh, that kind of mixes the bug fix and the feature in a way that it is
hard to understand.  How about this?

	Allow skipping of WAL for new tables and indexes if wal_level is
	'minimal' (Kyotaro Horiguchi)

	Relations larger than wal_skip_threshold will have their files
	fsync'ed rather than writing their WAL records.  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 +