Re: Corruption during WAL replay

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

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-25T01:59:08Z
Lists: pgsql-hackers
I wrote:
> ... 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.

Another thing that seems quite baffling, but is becoming clearer by
the hour, is that only serinus and dragonet are seeing this failure.
How is that?  They're not very similarly configured --- one is gcc,
one clang, and one uses jit and one doesn't.  They do share the same
perl version, 5.34.0; but so do twenty-three other animals, many of
which have reported in cleanly.  I'm at a loss to explain that.
Andres, can you think of anything that's peculiar to those two
animals?

			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.