Hi, On 2022-11-15 19:46:26 -0500, Tom Lane wrote: > Andres Freund <and...@anarazel.de> writes: > > To me it sounds like known_assigned_xids_lck is pointless and the talk about > > memory barriers a red herring, since all modifications have to happen with > > ProcArrayLock held exlusively and all reads with ProcArrayLock held in share > > mode. It can't be legal to modify head/tail or the contents of the array > > outside of that. And lwlocks provide sufficient barrier semantics. > > No ... RecordKnownAssignedTransactionIds calls KnownAssignedXidsAdd > with exclusive_lock = false, and in the typical case that will not > acquire ProcArrayLock at all. Since there's only one writer, that > seems safe enough, and I believe the commentary's claim that we > really just need to be sure the head-pointer update is seen > after the array updates.
Oh, right. I focussed to much on the part of the comment quoted in your email. I still think it's misleading for the comment to say that the tail can be modified with the spinlock - I don't see how that'd ever be correct. Nor could head be safely decreased with just the spinlock. Too bad, that seems to make the idea of compressing in other backends a non-starter unfortunately :(. Although - are we really gaining that much by avoiding ProcArrayLock in the RecordKnownAssignedTransactionIds() case? It only happens when latestObservedXid is increased, and we'll remove them at commit with the exclusive lock held. Afaict that's the only KAX access that doesn't also require ProcArrayLock? Greetings, Andres Freund
