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 по дате отправления: