Horton

Re: Making pg_rewind faster

John H <johnhyvr@gmail.com>

View thread
From: John H <johnhyvr@gmail.com>
To: Srinath Reddy Sadipiralla <srinath2133@gmail.com>
Cc: Michael Paquier <michael@paquier.xyz>, Robert Haas <robertmhaas@gmail.com>, wenhui qiu <qiuwenhuifx@gmail.com>, Japin Li <japinli@hotmail.com>, Andres Freund <andres@anarazel.de>, Alexander Korotkov <aekorotkov@gmail.com>, Justin Kwan <justinpkwan@outlook.com>, Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers <pgsql-hackers@postgresql.org>, vignesh ravichandran <admin@viggy28.dev>, "hlinnaka@iki.fi" <hlinnaka@iki.fi>
Date: 2025-10-23T22:01:32Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. pg_rewind: Skip copy of WAL segments generated before point of divergence

  2. pg_rewind: Extend code detecting relation files to work with WAL files

  3. Split TESTDIR into TESTLOGDIR and TESTDATADIR

Hi,

On Thu, Oct 23, 2025 at 9:08 AM Srinath Reddy Sadipiralla
<srinath2133@gmail.com> wrote:
> On Thu, Oct 23, 2025 at 1:52 PM Michael Paquier <michael@paquier.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