From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
cc: Robert Haas <robertmhaas@gmail.com>, Daniel Gustafsson <daniel@yesql.se>,
        Kyotaro Horiguchi <horikyota.ntt@gmail.com>, deniel1495@mail.ru,
        Ibrar Ahmed <ibrar.ahmad@gmail.com>, tejeswarm@hotmail.com,
        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: <20220325052654.3xpbmntatyofau2w@alap3.anarazel.de>
References: 
 <CA+TgmoYhFvsNedWw9eRJXPevy-RytpRMofbyETtU1SxUCG16-Q@mail.gmail.com>
 <3167047.1648169107@sss.pgh.pa.us>
 <CA+Tgmoa_TAJsUnFWzTevg=FzgXFyiHLJAY_L-jMDA=mH=ytysg@mail.gmail.com>
 <3170060.1648171358@sss.pgh.pa.us> <3173721.1648173548@sss.pgh.pa.us>
 <20220325022010.iqdj37tjqrqwxfrh@alap3.anarazel.de>
 <20220325024302.lhhi7jaapyetqviv@alap3.anarazel.de>
 <20220325034301.htu27xf54xjgyoca@alap3.anarazel.de>
 <3185871.1648181300@sss.pgh.pa.us>
 <20220325045438.enwakjqhrafzq5f2@alap3.anarazel.de>
 <20220325052654.3xpbmntatyofau2w@alap3.anarazel.de>
Comments: In-reply-to Andres Freund <andres@anarazel.de>
	message dated "Thu, 24 Mar 2022 22:26:54 -0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3193651.1648186725.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Fri, 25 Mar 2022 01:38:45 -0400
Message-ID: <3193652.1648186725@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/3193652.1648186725%40sss.pgh.pa.us>
Precedence: bulk

Andres Freund <andres@anarazel.de> writes:
> Ah, and that's finally also the explanation why I couldn't reproduce the
> failure it in a different directory, with an otherwise identically confi=
gured
> PG: The length of the path to the tablespace influences the size of the
> XLOG_TBLSPC_CREATE record.

Ooooohhh ... yeah, that could explain a lot of cross-animal variation.

> Not sure what to do here... I guess we can just change the value we over=
write
> the page with and hope to not hit this again? But that feels deeply deep=
ly
> unsatisfying.

AFAICS, this strategy of whacking a predetermined chunk of the page with
a predetermined value is going to fail 1-out-of-64K times.  We have to
change the test so that it's guaranteed to produce an invalid checksum.
Inverting just the checksum field, without doing anything else, would
do that ... but that feels pretty unsatisfying too.

			regards, tom lane