Re: PG 13 release notes, first draft

From: Noah Misch <noah(at)leadboat(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: PG 13 release notes, first draft
Date: 2020-05-08 04:22:02
Message-ID: 20200508042202.GA563018@rfd.leadboat.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, May 07, 2020 at 09:38:34AM -0400, Bruce Momjian wrote:
> On Wed, May 6, 2020 at 10:20:57PM -0700, Noah Misch wrote:
> > On Wed, May 06, 2020 at 07:40:25PM -0400, Bruce Momjian wrote:
> > > On Tue, May 5, 2020 at 11:39:10PM -0700, Noah Misch wrote:
> > > > On Mon, May 04, 2020 at 11:16:00PM -0400, Bruce Momjian wrote:
> > > > > Allow skipping of WAL for new tables and indexes if wal_level is 'minimal' (Noah Misch)
> > > >
> > > > Kyotaro Horiguchi authored that one. (I committed it.) The commit message
> > > > noted characteristics, some of which may deserve mention in the notes:
> > >
> > > Fixed.
> >
> > I don't see that change pushed (but it's not urgent).
>
> I got stuck on Amit's partition items and my head couldn't process any
> more, so I went to bed, and just committed it now. I was afraid to have
> pending stuff uncommitted, but I am also hesitant to do a commit for
> each change.

Got it, +1 for batching such changes.

> > > > - 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(at)leadboat(dot)com>
AuthorDate: Sat Apr 4 12:25:34 2020 -0700
Commit: Noah Misch <noah(at)leadboat(dot)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.

To maintain data durability, just before commit, we choose between an
fsync of the relfilenode and copying its contents to WAL. A new GUC,
wal_skip_threshold, guides that choice. If this change slows a workload
that creates small, permanent relfilenodes under wal_level=minimal, try
adjusting wal_skip_threshold. Users setting a timeout on COMMIT may
need to adjust that timeout, and log_min_duration_statement analysis
will reflect time consumption moving to COMMIT from commands like COPY.

Internally, this requires a reliable determination of whether
RollbackAndReleaseCurrentSubTransaction() would unlink a relation's
current relfilenode. Introduce rd_firstRelfilenodeSubid. Amend the
specification of rd_createSubid such that the field is zero when a new
rel has an old rd_node. Make relcache.c retain entries for certain
dropped relations until end of transaction.

Bump XLOG_PAGE_MAGIC, since this introduces XLOG_GIST_ASSIGN_LSN.
Future servers accept older WAL, so this bump is discretionary.

Kyotaro Horiguchi, reviewed (in earlier, similar versions) by Robert
Haas. Heikki Linnakangas and Michael Paquier implemented earlier
designs that materially clarified the problem. Reviewed, in earlier
designs, by Andrew Dunstan, Andres Freund, Alvaro Herrera, Tom Lane,
Fujii Masao, and Simon Riggs. Reported by Martijn van Oosterhout.

Discussion: https://postgr.es/m/20150702220524.GA9392@svana.org

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2020-05-08 04:36:33 Re: Fix pg_buffercache document
Previous Message Tom Lane 2020-05-08 03:30:23 Re: Logical replication subscription owner