This thread has gone for about a year here without making any
progress, which isn't great.
On Tue, Feb 7, 2023 at 2:49 PM Andres Freund <andres@anarazel.de> wrote:
> Hm. It's worrysome to now hold ProcArrayLock exclusively while iterating over
> the slots. ReplicationSlotsComputeRequiredXmin() can be called at a
> non-neglegible frequency. Callers like CreateInitDecodingContext(), that pass
> already_locked=true worry me a lot less, because obviously that's not a very
> frequent operation.
Maybe, but it would be good to have some data indicating whether this
is really an issue.
> I wonder if we could instead invert the locks, and hold
> ReplicationSlotControlLock until after ProcArraySetReplicationSlotXmin(), and
> acquire ProcArrayLock just for ProcArraySetReplicationSlotXmin(). That'd mean
> that already_locked = true callers have to do a bit more work (we have to be
> sure the locks are always acquired in the same order, or we end up in
> unresolved deadlock land), but I think we can live with that.
This seems like it could be made to work, but there's apparently a
shortage of people willing to write the patch.
As another thought, Masahiko-san writes in his proposed commit message:
"As a result, the replication_slot_xmin could be overwritten with an
old value and retreated."
But what about just surgically preventing that?
ProcArraySetReplicationSlotXmin() could refuse to retreat the values,
perhaps? If it computes an older value than what's there, it just does
nothing?
--
Robert Haas
EDB: http://www.enterprisedb.com