| From: | JoongHyuk Shin <sjh910805(at)gmail(dot)com> |
|---|---|
| To: | Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com> |
| Cc: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Persist slot invalidations before publishing them |
| Date: | 2026-09-13 10:31:57 |
| Message-ID: | CACSdjfOa0c1dqXZQhCBD+72tq6sOccfk1qs3SkYz+8Hgn=My5g@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi Bertrand,
I read v2 and have a question about the window the new ordering opens
between two invalidators.
As I understand it, in v2 the first invalidator acquires the slot,
writes the state file with the invalidation, and only after the fsync
sets data.invalidated in shared memory and releases the slot. While the
write is in progress the slot looks valid to everyone else, with the
invalidator's PID as active_pid. If a second invalidator reaches the
same slot in that window (say a restartpoint enforcing
max_slot_wal_keep_size while startup is replaying a wal_level change, or
the other way round), it seems it would take the "slot is in use" path,
so startup might send a recovery conflict to active_pid, or another
process a SIGTERM. What do you think?
--
JoongHyuk Shin
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Nikolay Samokhvalov | 2026-09-13 11:32:37 | [PATCH] validate inherited check constraints when enabling enforcement |
| Previous Message | Xuneng Zhou | 2026-09-13 09:57:18 | Re: Implement waiting for wal lsn replay: reloaded |