Re: Making pg_rewind faster

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Justin Kwan <justinpkwan(at)outlook(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, vignesh <vignesh(at)cloudflare(dot)com>, "jkwan(at)cloudflare(dot)com" <jkwan(at)cloudflare(dot)com>, vignesh ravichandran <admin(at)viggy28(dot)dev>, "hlinnaka(at)iki(dot)fi" <hlinnaka(at)iki(dot)fi>
Subject: Re: Making pg_rewind faster
Date: 2022-07-19 05:36:25
Message-ID: YtZCNZUNQWifrqz2@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jul 18, 2022 at 05:14:00PM +0000, Justin Kwan wrote:
> Thank you for taking a look at this and that sounds good. I will
> send over a patch compatible with Postgres v16.

+$node_2->psql(
+ 'postgres',
+ "SELECT extract(epoch from modification) FROM pg_stat_file('pg_wal/000000010000000000000003');",
+ stdout => \my $last_common_tli1_wal_last_modified_at);
Please note that you should not rely on the FS-level stats for
anything that touches the WAL segments. A rough guess about what you
could here to make sure that only the set of WAL segments you are
looking for is being copied over would be to either:
- Scan the logs produced by pg_rewind and see if the segments are
copied or not, depending on the divergence point (aka the last
checkpoint before WAL forked).
- Clean up pg_wal/ in the target node before running pg_rewind,
checking that only the segments you want are available once the
operation completes.
--
Michael

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2022-07-19 05:45:15 Re: Windows now has fdatasync()
Previous Message Peter Smith 2022-07-19 05:31:04 Re: System catalog documentation chapter