Thomas Munro <thomas.munro@gmail.com> writes:
> On Tue, Oct 28, 2025 at 9:12 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I'm unsure if we've got any infrastructure that'd allow setting the
>> tuple's match bit in a more atomic fashion.
> Interesting problem. My first drive-by thought is that we would need:
> some new smaller atomics (that's a 16 bit member), and a decision that
> it is OK to use the atomics API by casting (should be OK, since we no
> longer have emulated atomics in smaller sizes, so now it's just a
> fancy way of accessing memory with "boxed" types that have the same
> size and alignment as the underlying type, and plain stores should
> work for initialisation if careful about synchronisation).
Right. I wasn't excited about building out 16-bit atomics, not least
because I'm unsure that those exist on every supported architecture.
Instead I spent a little time thinking about how we could use a 32-bit
atomic op here. Clearly, that should theoretically work, but you'd
have to identify where is the start of the 32-bit word (t_infomask2
sadly is not at a 4-byte boundary) and which bit within that word is
the target bit (that's gonna vary depending on endianness at least).
Seems like a pain in the rear, but probably still less work than
creating 16-bit atomic ops.
A vaguer thought is that we're not bound to represent the match
bit in exactly the way it's done now, if there's some other choice
that would be easier to fit into these concerns. The only hard
limit I'd lay down is that making the struct bigger isn't OK.
> I guess
> the op we'd want is atomic_fetch_or with a check of the old value to
> see if you lost the race.
I was thinking about CAS, but at some level these are all equivalent.
> I suppose the smallest code change would be
> to keep the existing code flow that was apparently almost working here
> (the window of optimism being just between the relaxed check at the
> top and the set at the bottom). If you fail to be the first to set
> the bit, you abandon the work done, but it should hopefully be rare
> enough and cheaper overall than something "pessimistic" that does
> something akin to locking the tuple while thinking about it,
Right. If we encounter the race condition and lose it, we'd have
wasted the time for an extra evaluation of the joinqual, but that
should be fine given that we know this is rare. (And we'd not be
using this plan shape if the joinqual were volatile.)
regards, tom lane
