Re: Making pg_rewind faster

Hi everyone!

Here's the attached patch submission to optimize pg_rewind performance when many WAL files are retained on server. This patch avoids replaying (copying over) older WAL segment files that fall before the point of divergence between the source and target servers.

Thanks,
Justin
________________________________
From: Justin Kwan <jkwan(at)cloudflare(dot)com>
Sent: July 15, 2022 6:13 PM
To: vignesh ravichandran <admin(at)viggy28(dot)dev>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>; vignesh <vignesh(at)cloudflare(dot)com>; justinpkwan(at)outlook(dot)com <justinpkwan(at)outlook(dot)com>
Subject: Re: Making pg_rewind faster

Looping in my other email.

On Thu, Jun 30, 2022 at 6:22 AM vignesh ravichandran <admin(at)viggy28(dot)dev<mailto:admin(at)viggy28(dot)dev>> wrote:
Hi Hackers,

I have been using pg_rewind in production for 2 years. One of the things that I noticed in pg_rewind is if it doesn't know what to do with a file "it copies". I understand it's the more safer option. After all, the alternative, pg_basebackup copies all the files from source to target.

However, this is making pg_rewind inefficient when we have a high number of WAL files. Majority of the data (in most of my cases 95%+) that it copies are WAL files which are anyway same between the source and target. Skipping those same WAL files from copying will improve the speed of pg_rewind a lot.

1. Does pg_rewind need to copy WAL files before the WAL that contains the last common check point?

Heikki's presentation https://pgsessions.com/assets/archives/pg_rewind-presentation-paris.pdf gave me a good overview and also explained the behavior what I mentioned.

Thanks,
Vignesh