| From: | Andrey Borodin <x4mmm(at)yandex-team(dot)ru> |
|---|---|
| To: | Alexander Lakhin <exclusion(at)gmail(dot)com> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, "Zhijie Hou (Fujitsu)" <houzj(dot)fnst(at)fujitsu(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: walsummarizer can get stuck when switching timelines |
| Date: | 2026-08-23 16:02:52 |
| Message-ID: | 4E457411-34B8-4E5A-961A-199FC4014E67@yandex-team.ru |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi Alexander,
> 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.
I think either is correct here. CREATE TABLE has already committed
before the SELECT is executed.
AFAIU important part for avoiding the race is to record the LSN before
wait_for_replay_catchup(), rather than afterwards. The wait then
guarantees that node2 has replayed at least the recorded position, while
WAL generated later on node1 cannot move that position past node2's
eventual fork point.
I'd keep pg_current_wal_insert_lsn(), it matches what
wait_for_replay_catchup() uses.
Best regards, Andrey Borodin.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrey Borodin | 2026-08-23 16:28:47 | Re: [PATCH] Fix vacuum_delay_point happening inside lock |
| Previous Message | Andrew Dunstan | 2026-08-23 15:22:31 | Re: PGQ catalog representation and pg_dump support |