Re: walsummarizer can get stuck when switching timelines

Hi Andrey,

20.08.2026 21:43, Andrey Borodin wrote:
> 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?
>

I wonder if $node1_final_lsn should be pg_current_wal_flush_lsn instead of
pg_current_wal_insert_lsn. I've tried flush_lsn and it seems to fix the
issue, but I'm not sure if it's correct test-wise.

Best regards,
Alexander