Re: [EXTERNAL]Re: BUG #19094: select statement on postgres 17 vs postgres 18 is returning different/duplicate results

On Thu, Oct 30, 2025 at 5:11 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> 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.

Here's a quick patch to experiment with that idea. It applies on top
of the <stdatomic.h> patches I posted yesterday[1]. The following
looks quite nice to my eye, but there might be other ways that make
fewer assumptions (see XXX comments in patch):

/*
* Atomically set the match flag and report whether it was already set. False
* means that the caller was the first to set it.
*/
static inline bool
HeapTupleHeaderTestAndSetMatch(MinimalTupleData *tup)
{
return atomic_fetch_or(pg_atomic_cast(&tup->t_infomask2),
HEAP_TUPLE_HAS_MATCH) & HEAP_TUPLE_HAS_MATCH;
}

[1] https://www.postgresql.org/message-id/flat/CA%2BhUKGKFvu3zyvv3aaj5hHs9VtWcjFAmisOwOc7aOZNc5AF3NA%40mail.gmail.com