pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Bruce Momjian <bruce@momjian.us>
To: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Cc: noah@leadboat.com
Cc: pgsql-hackers@postgresql.org
Subject: Re: PG 13 release notes, first draft
Date: Wed, 13 May 2020 11:15:18 -0400
Message-ID: <20200513151518.GA20111@momjian.us> (raw)
In-Reply-To: <20200513.115633.157251733478541458.horikyota.ntt@gmail.com>
References: <20200512001204.GF4666@momjian.us>
	<20200512.130908.2082912530895654639.horikyota.ntt@gmail.com>
	<20200512203809.GA4666@momjian.us>
	<20200513.115633.157251733478541458.horikyota.ntt@gmail.com>

On Wed, May 13, 2020 at 11:56:33AM +0900, Kyotaro Horiguchi wrote:
> > 
> > 	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.
> 
> I see it. It is giving weight on improvement. Looks good the overall
> structure of the description above.  However, wal-skipping is always
> done regardless of table size. wal_skip_threshold is an optimization
> to choose which to use fsync or FPI records (that is, not WAL records
> in the common sense) at commit for speed.

Well, as far as users are concerned, everything wrtiten to  WAL is a WAL
record.

> So how about the following?
> 
> All kinds of bulk-insertion are not WAL-logged then fsync'ed at
> commit.  Using FPI WAL records instead of fsync for relations smaller
> than wal_skip_threshold. Previously this was done only for COPY
> operations and always using fsync, but the implementation had a bug
> that could cause data loss during crash recovery.

That is too much detail for the release notes.  We already will link to
the docs.  Why put it here?

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





view thread (194+ messages)  latest in thread

Message-ID: <20200513151518.GA20111@momjian.us>
Permalink:  ../20200513151518.GA20111@momjian.us/
Also on:    postgresql.org/message-id/20200513151518.GA20111@momjian.us

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: bruce@momjian.us, horikyota.ntt@gmail.com, noah@leadboat.com
  Subject: Re: PG 13 release notes, first draft
  In-Reply-To: <20200513151518.GA20111@momjian.us>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox