Re: Wrong results: hashed SubPlan referenced twice after OR-qual extraction reuses a stale hash table (13 to 19beta4)

Hi Alex,

On Fri, Oct 16, 2026, Alexandra Wang wrote:
> I tested v1-0001 on current master (6b3f8857aa8) and it looks good to
> me overall.

Thanks for testing and reviewing it!

> One minor question: with hashtablestale in place, do we still need the
> "planstate->chgParam != NULL" test in ExecHashSubPlan()?

No, I don't think we do.  The only place that sets chgParam on the
subplan of a hashed SubPlan is the subPlan loop in ExecReScan(), and
v1 already sets hashtablestale right there.  The attached v2 drops the
test, so the flag is the only signal.  Otherwise it's the same as v1,
rebased on current master.

> I also found a related bug in the EPQ recheck code, using the same
> query shape.

Nice catch.  I can reproduce it on current master (7787aec8ab), with
the same results you got: your FOR UPDATE query is fixed by your
change alone, and the FOR UPDATE variant of the join query needs both
fixes.

> Do you think this can go together with your fix?  Or would you prefer
> it as a separate patch?

I'd prefer a separate patch.  It's a different mechanism in different
code, and each fix can be committed without the other.  Could you post
it in a new thread with its own commitfest entry, along with your
isolation spec?  That also lets cfbot test each patch on its own.  A
link back to this thread would help, since the FOR UPDATE join query
needs both fixes.  I'm happy to review it.

With v2, the regression, isolation and contrib tests pass (I haven't
run the TAP tests).  I still owe back-branch versions; I'll post them
once the master version is settled.

Regards,
Rahul Yadav