From: Tom Lane <tgl@sss.pgh.pa.us>
To: Noah Misch <noah@leadboat.com>
Cc: Mark Dilger <mark.dilger@enterprisedb.com>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: Fixing WAL instability in various TAP tests
Date: Sat, 25 Sep 2021 12:20:39 -0400
Message-ID: <2517015.1632586839@sss.pgh.pa.us> (raw)
In-Reply-To: <20210925160039.GA4134968@rfd.leadboat.com>
References: <32A1FDD1-9C7B-43B1-B3EE-49198DD3F887@enterprisedb.com>
<20210925052151.GA4082552@rfd.leadboat.com>
<2E9D28A3-1B54-446B-AC12-3BF86A2B522A@enterprisedb.com>
<2502590.1632579467@sss.pgh.pa.us>
<2B4C64CF-EE3F-474B-9685-6A927E5E49AE@enterprisedb.com>
<20210925160039.GA4134968@rfd.leadboat.com>
Noah Misch <noah@leadboat.com> writes:
> On Sat, Sep 25, 2021 at 08:20:06AM -0700, Mark Dilger wrote:
>> You may be right, but the conversation about "all possible settings" was
>> started by Noah.
> You wrote, "I would expect tests which fail under legal alternate GUC settings
> to be hardened to explicitly set the GUCs as they need, rather than implicitly
> relying on the defaults." I read that as raising the general principle, not
> just a narrow argument about max_wal_size.
As did I.
> We can discontinue talking about
> the general principle and focus on max_wal_size.
It is worth stopping to think about whether there are adjacent settings
that need similar treatment.
In general, it seems like "premature discarding of WAL segments" is
something akin to "premature timeout" errors, and we've got a pretty
aggressive policy about preventing those. There are a lot of settings
that I'd *not* be in favor of trying to be bulletproof about, because
it doesn't seem worth the trouble; but perhaps this one is.
regards, tom lane
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: tgl@sss.pgh.pa.us, noah@leadboat.com, mark.dilger@enterprisedb.com
Subject: Re: Fixing WAL instability in various TAP tests
In-Reply-To: <2517015.1632586839@sss.pgh.pa.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