Re: Making pg_rewind faster

Michael Paquier <michael@paquier.xyz>

From: Michael Paquier <michael@paquier.xyz>
To: Srinath Reddy Sadipiralla <srinath2133@gmail.com>
Cc: John H <johnhyvr@gmail.com>, 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-25T01:15:53Z
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

On Fri, Oct 24, 2025 at 05:51:54PM +0530, Srinath Reddy Sadipiralla wrote:
> -        * These files exist on the source and the target services, so they
> should
> +        * These files exist on the source and the target servers, so they
> should

Not sure what my fingers were doing here.

> I think as we are not using mtime to show that the file has not been copied
> and been skipped ,instead we are doing the same with the debug message
> (qr/pg_wal\/$wal_seg_skipped \(NONE\)/,), so stat calculation of this WAL
> segment can be removed.

Yes, removing this one makes sense.

And, to keep it short: applied.
--
Michael