Hi, On Thu, Oct 23, 2025 at 9:08 AM Srinath Reddy Sadipiralla <[email protected]> wrote: > On Thu, Oct 23, 2025 at 1:52 PM Michael Paquier <[email protected]> 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
