From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
cc: Daniel Gustafsson <daniel@yesql.se>,
        Kyotaro Horiguchi <horikyota.ntt@gmail.com>, deniel1495@mail.ru,
        Ibrar Ahmed <ibrar.ahmad@gmail.com>, tejeswarm@hotmail.com,
        Andres Freund <andres@anarazel.de>, hlinnaka <hlinnaka@iki.fi>,
        Masahiko Sawada <masahiko.sawada@2ndquadrant.com>,
        "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>,
        Daniel Wood <hexexpert@comcast.net>
Subject: Re: Corruption during WAL replay
In-reply-to: 
 <CA+Tgmoa_TAJsUnFWzTevg=FzgXFyiHLJAY_L-jMDA=mH=ytysg@mail.gmail.com>
References: 
 <CA+TgmoYhYrMajsDFMN4r0c4d93MdxxsJdgDVe01FSHm0M3NFyg@mail.gmail.com>
 <20220316.141432.2298656526174566963.horikyota.ntt@gmail.com>
 <CA+TgmobNVosCR02Wpfa2QFnGwu66b81BcX+r2T_6u719E9wBwQ@mail.gmail.com>
 <20220318.102109.162855329039722212.horikyota.ntt@gmail.com>
 <CA+TgmoYqgB8NjTgw6pZsA-RVo4qF8i9CPfqK07sjs6DLGCDf6Q@mail.gmail.com>
 <3152696.1648159485@sss.pgh.pa.us>
 <CA+TgmoYG4-P8PUWPVZyCjR0_kUwfY0KFRJcO7WGO2fi7icGTpA@mail.gmail.com>
 <CA+TgmoYhFvsNedWw9eRJXPevy-RytpRMofbyETtU1SxUCG16-Q@mail.gmail.com>
 <3167047.1648169107@sss.pgh.pa.us>
 <CA+Tgmoa_TAJsUnFWzTevg=FzgXFyiHLJAY_L-jMDA=mH=ytysg@mail.gmail.com>
Comments: In-reply-to Robert Haas <robertmhaas@gmail.com>
	message dated "Thu, 24 Mar 2022 21:08:23 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3170059.1648171358.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Thu, 24 Mar 2022 21:22:38 -0400
Message-ID: <3170060.1648171358@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/3170060.1648171358%40sss.pgh.pa.us>
Precedence: bulk

Robert Haas <robertmhaas@gmail.com> writes:
> I hate to say "no" because the evidence suggests that the answer might
> be "yes" -- but it definitely isn't intending to change anything about
> the shutdown sequence. It just introduces a mechanism to backends to
> force the checkpointer to delay writing the checkpoint record.

Wait a minute, I think we may be barking up the wrong tree.

The three commits that serinus saw as new in its first failure were

ce95c54376 Thu Mar 24 20:33:13 2022 UTC  Fix pg_statio_all_tables view for=
 multiple TOAST indexes. =

7dac61402e Thu Mar 24 19:51:40 2022 UTC  Remove unused module imports from=
 TAP tests =

412ad7a556 Thu Mar 24 18:52:28 2022 UTC  Fix possible recovery trouble if =
TRUNCATE overlaps a checkpoint.

I failed to look closely at dragonet, but I now see that its
first failure saw

ce95c54376 Thu Mar 24 20:33:13 2022 UTC  Fix pg_statio_all_tables view for=
 multiple TOAST indexes. =

7dac61402e Thu Mar 24 19:51:40 2022 UTC  Remove unused module imports from=
 TAP tests

serinus is 0-for-3 since then, and dragonet 0-for-4, so we can be pretty
confident that the failure is repeatable for them.  That means that the
culprit must be ce95c54376 or 7dac61402e, not anything nearby such as
412ad7a556.

It's *really* hard to see how the pg_statio_all_tables change could
have affected this.  So that leaves 7dac61402e, which did this to
the test script that's failing:
 =

 use strict;
 use warnings;
-use Config;
 use PostgreSQL::Test::Cluster;
 use PostgreSQL::Test::Utils;

Discuss.

			regards, tom lane