Re: Making pg_rewind faster

Hi,

On Thu, Oct 23, 2025 at 9:08 AM Srinath Reddy Sadipiralla
<srinath2133(at)gmail(dot)com> wrote:
> On Thu, Oct 23, 2025 at 1:52 PM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>>
>> FWIW, I am definitely not a fan of the test relying on the timestamp
>> of the files based on their retrieved meta-data stats, with the mtime.
>> I suspect complications on Windows. Worse thing, there is a forced
>> sleep of 1s added to the test, to make sure that the timestamp of the
>> files we compare have a different number. But do we really need that
>> anyway if we have the debug information with the file map printed in
>> it?
>
>
> thought it would act like an extra sanity check ,to prove the point that the
> pg_rewind is saying through the debug info that it has been really copied
> or skipped.
>

I don't feel too strongly about it. If we want to rely on checking debug log
that works for me. We don't do any in-depth checks that every file was
properly copied anyway for existing files.

> ...
> i guess this is what you want ,please let me know if it's otherwise,
> ...

That looks right to me.

>>
>> It seems to me that it would be good for the test to run some sanity
>> checks on the rewound standby, as well. That would provide more
>> validation for the case of the "corrupted" segment that gets copied
>> anyway.
>
> ...
> 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.

--
John Hsu - Amazon Web Services