Re: Corruption during WAL replay - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Corruption during WAL replay
Date
Msg-id 20220325012347.rtu37s7x7k3xmzg4@alap3.anarazel.de
Whole thread Raw
In response to Re: Corruption during WAL replay  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Hi,

On 2022-03-24 20:39:27 -0400, Robert Haas wrote:
> But that leaves me even more confused. How can a change to only the server
> code cause a client utility to fail to detect corruption that is being
> created by Perl while the server is stopped?

I guess it could somehow cause the first page to be all zeroes, in which case
overwriting it with more zeroes wouldn't cause a problem that pg_checksums can
see?  But I have a somewhat more realistic idea:

I'm suspicious of pg_checksums --filenode. If I understand correctly
--filenode scans the data directory, including all tablespaces, for a file
matching that filenode. If we somehow end up with a leftover file in the pre
ALTER TABLE SET TABLESPACE location, it'd not notice that there *also* is a
file in a different place?

Perhaps the --filenode mode should print out the file location...


Randomly noticed: The test fetches the block size without doing anything with
it afaics.

Andres



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Corruption during WAL replay
Next
From: Tatsuo Ishii
Date:
Subject: Re: [HACKERS] WIP aPatch: Pgbench Serialization and deadlock errors