Re: Making pg_rewind faster - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Making pg_rewind faster
Date
Msg-id aPsxMUt8CYvCKINU@paquier.xyz
Whole thread Raw
In response to Re: Making pg_rewind faster  (John H <johnhyvr@gmail.com>)
Responses Re: Making pg_rewind faster
List pgsql-hackers
On Thu, Oct 23, 2025 at 03:01:32PM -0700, John H wrote:
> On Thu, Oct 23, 2025 at 9:08 AM Srinath Reddy Sadipiralla <srinath2133@gmail.com> wrote:
>> ...
>> i guess this is what you want ,please let me know if it's otherwise,
>> ...
>
> That looks right to me.

Yes, that would be something among these lines, WAL segments being
treated as an exception when printing the file map to show that they
are not copied.

>> These checks show that before the corrupt segment's size on
>> rewound standby(target) was not the same as source but after
>> rewind it was the same as source,please let me know if i am
>> missing your point here.
>
> What did you have in mind for additional sanity checks?
> The existing test checks that when sizes are different the correct
> branch is taken. For something more in-depth that requires comparing
> data before and after the rewind with a "corrupted" segment that seems
> complicated since the segment would have to somehow be applied to
> writer but not replica prior to divergence.

I was just wondering about some queries on the new standby once we are
done with the rewind.  But after sleeping on it, I'd be happy with
just the set of tests we have: the debug output checks, the size
checks pre and post-rewind, and no mtime.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: "Hayato Kuroda (Fujitsu)"
Date:
Subject: RE: issue with synchronized_standby_slots
Next
From: Andrew Kim
Date:
Subject: Re: Proposal for enabling auto-vectorization for checksum calculations