Horton

Re: Corruption during WAL replay

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
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>
Date: 2022-03-25T04:08:20Z
Lists: pgsql-hackers 
Andres Freund <andres@anarazel.de> writes:
> The only thing I can really conclude here is that we apparently end up with
> the same checksum for exactly the modifications we are doing? Just on those
> two damn instances? Reliably?

IIRC, the table's OID or relfilenode enters into the checksum.
Could it be that assigning a specific OID to the table allows
this to happen, and these two animals are somehow assigning
that OID while others are using some slightly different OID?

			regards, tom lane

Commits

  1. Harden TAP tests that intentionally corrupt page checksums.

  2. Fix possible recovery trouble if TRUNCATE overlaps a checkpoint.

  3. Remember to reset yy_start state when firing up repl_scanner.l.