Re: Persist slot invalidations before publishing them

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

In response to

Browse pgsql-hackers by date

  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