Re: walsummarizer can get stuck when switching timelines

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.