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

On Tue, Oct 28, 2025 at 11:04 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Richard Guo <guofenglinux(at)gmail(dot)com> writes:
> > AFAICT, there are 3 possible options for a fix.
>
> > 1) Revert aa86129e1.
>
> > 2) Modify the code to perform atomic operations on the matched flag
> > using a CAS (or a similar) mechanism when running in parallel
> > execution.
>
> > 3) Disable parallel right semi joins in the planner.

> Right. I agree that #3 is the most attractive stopgap answer.
> We can look into #2 later, but it doesn't sound like something
> to back-patch. (The main problem according to my brief look
> is that t_infomask2 is uint16, but we haven't built out any
> 16-bit atomic primitives; perhaps they do not exist everywhere.)

Agreed. Here's a patch that follows along the lines of option #3.

> > (I'm still trying to understand why concurrent access to the matched
> > flag in cases other than right semi joins (such as right or full
> > joins) doesn't lead to concurrency issues.)
>
> I believe PRSJ is the only case where we need to set and concurrently
> inspect the HEAP_TUPLE_HAS_MATCH flag in a shared hashtable.

Right. In the case of RIGHT or FULL joins, the match flags are used
to emit the unmatched inner tuples, and the scan for unmatched inner
tuples occurs after we have finished a batch. Therefore, concurrent
inspection and setting of the match flags does not break correctness.

- Richard