From: Noah Misch <noah@leadboat.com>
To: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Cc: robertmhaas@gmail.com
Cc: pgsql-hackers@postgresql.org
Cc: 9erthalion6@gmail.com
Cc: andrew.dunstan@2ndquadrant.com
Cc: hlinnaka@iki.fi
Cc: michael@paquier.xyz
Subject: Re: [HACKERS] WAL logging problem in 9.4.3?
Date: Sun, 8 Dec 2019 10:09:51 -0800
Message-ID: <20191208180951.GA1694300@rfd.leadboat.com> (raw)
In-Reply-To: <20191203.205146.1521643852457054060.horikyota.ntt@gmail.com>
References: <20191128.205620.2015649987051831334.horikyota.ntt@gmail.com>
<20191128.213508.1108483203561250557.horikyota.ntt@gmail.com>
<20191128222319.GA89611@gust.leadboat.com>
<20191203.205146.1521643852457054060.horikyota.ntt@gmail.com>
I reviewed your latest code, and it's nearly complete. mdimmedsync() syncs
only "active segments" (as defined in md.c), but smgrDoPendingSyncs() must
sync active and inactive segments. This matters when mdtruncate() truncated
the relation after the last checkpoint, causing active segments to become
inactive. In such cases, syncs of the inactive segments will have been queued
for execution during the next checkpoint. Since we skipped the
XLOG_SMGR_TRUNCATE record, we must complete those syncs before commit. Let's
just modify smgrimmedsync() to always sync active and inactive segments;
that's fine to do in other smgrimmedsync() callers, even though they operate
on relations that can't have inactive segments.
On Tue, Dec 03, 2019 at 08:51:46PM +0900, Kyotaro Horiguchi wrote:
> At Thu, 28 Nov 2019 17:23:19 -0500, Noah Misch <noah@leadboat.com> wrote in
> > On Thu, Nov 28, 2019 at 09:35:08PM +0900, Kyotaro Horiguchi wrote:
> > > I measured the performance with the latest patch set.
> > >
> > > > 1. Determine $DDL_COUNT, a number of DDL transactions that take about one
> > > > minute when done via syncs.
> > > > 2. Start "pgbench -rP1 --progress-timestamp -T180 -c10 -j10".
> > > > 3. Wait 10s.
> > > > 4. Start one DDL backend that runs $DDL_COUNT transactions.
> > > > 5. Save DDL start timestamp, DDL end timestamp, and pgbench output.
> wal_buffers | 512
This value (4 MiB) is lower than a tuned production system would have. In
future benchmarks (if any) use wal_buffers=2048 (16 MiB).
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: noah@leadboat.com, horikyota.ntt@gmail.com, robertmhaas@gmail.com, 9erthalion6@gmail.com, andrew.dunstan@2ndquadrant.com, hlinnaka@iki.fi, michael@paquier.xyz
Subject: Re: [HACKERS] WAL logging problem in 9.4.3?
In-Reply-To: <20191208180951.GA1694300@rfd.leadboat.com>
* 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