Re: walsummarizer can get stuck when switching timelines - Mailing list pgsql-hackers

From Andrey Borodin
Subject Re: walsummarizer can get stuck when switching timelines
Date
Msg-id 55A6AB0E-D4A8-43CD-B79B-2CD5D5828C45@yandex-team.ru
Whole thread
In response to Re: walsummarizer can get stuck when switching timelines  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: [GSoC 2026] - B-tree Index Bloat Reduction - Approach & Questions
Re: [GSoC 2026] - B-tree Index Bloat Reduction - Approach & Questions
Re: [GSoC 2026] - B-tree Index Bloat Reduction - Approach & Questions
List pgsql-hackers
Hi Alexander,

On Mon, Aug 17, 2026 at 11:00 AM Alexander Lakhin wrote:
> So I guess, the test failed due to bgwriter's LogStandbySnapshot.

I think you are right. The test records node1_final_lsn after waiting
for node2 to catch up. Any WAL generated on node1 between those two
operations can therefore move node1_final_lsn past the point from which
node2 is later promoted.

Perhaps we should instead obtain the LSN together with the operation
whose WAL we want node2 to replay, and only then wait for catchup:

my $node1_final_lsn = $node1->safe_psql('postgres', <<EOM);
CREATE TABLE dummy ();
SELECT pg_current_wal_insert_lsn();
EOM
$node1->wait_for_replay_catchup($node2);

This way node1_final_lsn identifies the position immediately after the
test's own pre-promotion WAL, and wait_for_replay_catchup() guarantees
that node2 has replayed at least that far. Any WAL generated on node1
afterwards can no longer move the reference point past node2's fork
point.

WDYT?

Thank you!

Best regards, Andrey Borodin.




pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: GIN page deletion and page recycling bugs
Next
From: Jeff Davis
Date:
Subject: Re: Fix for fragile code in hashtext()