Date: Mon, 11 May 2020 20:12:04 -0400
From: Bruce Momjian <bruce@momjian.us>
To: Noah Misch <noah@leadboat.com>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: PG 13 release notes, first draft
Message-ID: <20200512001204.GF4666@momjian.us>
References: <20200505031600.GB21752@momjian.us>
 <20200506063910.GA515983@rfd.leadboat.com>
 <20200506234025.GC3649@momjian.us>
 <20200507052057.GB541283@rfd.leadboat.com>
 <20200507133834.GJ3649@momjian.us>
 <20200508042202.GA563018@rfd.leadboat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200508042202.GA563018@rfd.leadboat.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Precedence: bulk

On Thu, May  7, 2020 at 09:22:02PM -0700, Noah Misch wrote:
> On Thu, May 07, 2020 at 09:38:34AM -0400, Bruce Momjian wrote:
> > > > > - Crash recovery was losing tuples written via COPY TO.  This fixes the bug.
> > > > 
> > > > This was not backpatched?
> > > 
> > > Right.
> > 
> > Oh.  So you are saying we could lose COPY data on a crash, even after a
> > commit.  That seems bad.  Can you show me the commit info?  I can't find
> > it.
> 
> 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?

-- 
  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 +