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

Hi All,

Does this mean that a v18 patch will be available that we can download?

https://www.postgresql.org/

Many thanks for addressing this so quickly.

Thank you.
Lori

-----Original Message-----
From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Sent: Thursday, October 30, 2025 12:12 AM
To: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Cc: Richard Guo <guofenglinux(at)gmail(dot)com>; Lori Corbani <Lori(dot)Corbani(at)jax(dot)org>; pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: [EXTERNAL]Re: BUG #19094: select statement on postgres 17 vs postgres 18 is returning different/duplicate results

Thomas Munro <thomas(dot)munro(at)gmail(dot)com> writes:
> On Tue, Oct 28, 2025 at 9:12 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
---

The information in this email, including attachments, may be confidential and is intended solely for the addressee(s). If you believe you received this email by mistake, please notify the sender by return email as soon as possible.