| From: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> |
|---|---|
| To: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Cc: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Zhijie Hou <houzhijie22(at)gmail(dot)com> |
| Subject: | Assertion failure in update_local_synced_slot(), slotsync.c:364 |
| Date: | 2026-11-09 20:04:38 |
| Message-ID: | CAD21AoDdn9QJ2Q5dNkW9dAAzvoH-9yEF7jw64QpHJGqi3YJMvQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi all,
While reviewing slotsync.c, I hit the assertion failure:
TRAP: failed Assert("MyReplicationSlot->data.persistency ==
RS_TEMPORARY"), slotsync.c:364
IIUC this is a regression of commit 788ec96d591 (CC'ed Hou and Amit).
In update_local_synced_slot(), we try to advance the local slot only
when the remote slot is ahead of it, and if the standby cannot reach a
consistent snapshot we set the skip reason to
SS_SKIP_NO_CONSISTENT_SNAPSHOT so that
update_and_persist_local_synced_slot() doesn't persist the slot.
However, LogicalSlotAdvanceAndCheckSnapState() has already advanced
confirmed_flush_lsn to the remote's value in that case (restart_lsn
and catalog_xmin were already equal to the remote's when the slot was
created). So in the next cycle the remote slot is no longer ahead, we
skip the advance entirely, and update_slotsync_skip_stats() overwrites
the skip reason with SS_SKIP_NONE.
update_and_persist_local_synced_slot() then persists the slot and
reports it as sync-ready even though nothing has changed since the
previous cycle. Once the remote slot advances again and the standby
still cannot find a consistent snapshot, the assertion above fails.
On non-assert builds, IIUC the problem is worse: the persisted slot
can be used after promotion, and decoding from it skips the
transactions between its restart_lsn and the first consistent point,
causing data loss.
Before that commit, update_and_persist_local_synced_slot() also
checked found_consistent_snapshot returned by
update_local_synced_slot() for the current cycle, so a cycle that
didn't attempt to advance the slot never persisted it.
I've attached a TAP test to reproduce this issue, generated by AI.
Regards,
--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com
| Attachment | Content-Type | Size |
|---|---|---|
| 0001-Add-test-for-slot-sync-persisting-a-slot-without-a-c.patch | text/x-patch | 4.7 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Nathan Bossart | 2026-11-09 20:50:21 | Re: Logical Implication |
| Previous Message | Matheus Alcantara | 2026-11-09 20:03:11 | Re: extension_control_path: ignore empty elements and deduplicate directories |