Re: Corruption during WAL replay
От | Andres Freund |
---|---|
Тема | Re: Corruption during WAL replay |
Дата | |
Msg-id | 20220325012347.rtu37s7x7k3xmzg4@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: Corruption during WAL replay (Robert Haas <robertmhaas@gmail.com>) |
Список | 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 по дате отправления: