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

From Tom Lane
Subject Re: Corruption during WAL replay
Date
Msg-id 3167047.1648169107@sss.pgh.pa.us
Whole thread Raw
In response to Re: Corruption during WAL replay  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Corruption during WAL replay  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> And ... right after hitting send, I see that the recovery check
> failures are under separate troubleshooting and thus probably
> unrelated.

Yeah, we've been chasing those for months.

> 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?

Hmm, I'd supposed that the failing test cases were new as of 412ad7a55.
Now I see they're not, which indeed puts quite a different spin on
things.  Your thought about maybe the server isn't shut down yet is
interesting --- did 412ad7a55 touch anything about the shutdown
sequence?

            regards, tom lane



pgsql-hackers by date:

Previous
From: Japin Li
Date:
Subject: Re: [PATCH] add relation and block-level filtering to pg_waldump
Next
From: Thomas Munro
Date:
Subject: Re: [PATCH] add relation and block-level filtering to pg_waldump