Re: PG 13 release notes, first draft

From: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
To: bruce(at)momjian(dot)us
Cc: noah(at)leadboat(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: PG 13 release notes, first draft
Date: 2020-05-14 06:23:02
Message-ID: 20200514.152302.1177850100727636120.horikyota.ntt@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

At Wed, 13 May 2020 22:40:52 -0400, Bruce Momjian <bruce(at)momjian(dot)us> wrote in
> 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(at)momjian(dot)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.

Although I can't help feeling it out-of-point a bit, it is right in
apperarance. So, I don't object it.

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2020-05-14 06:27:37 Re: SLRU statistics
Previous Message Amit Kapila 2020-05-14 06:17:59 Re: Parallel copy