Hello,
> > This issue is that some query returns duplicate rows after FOR
> > UPDATE was blocked, in other words, after getting
> > HeapTupleUpdated in ExecLockRows.
>
> Good catch!
Thank you.
> > In the EPQ block in ExecScanFetch, it seems should return NULL if
> > the relation does not has test tuple. The attached patch does so
> > on the current master and the problem has disappeared.
>
> ... but bad fix. This would break join cases, wherein it's important
> that other scan nodes still return all the required tuples. (It's
> unfortunate that the eval-plan-qual isolation test fails to cover
> joins :-(.)
Hmm. I regretfully forgot to do isolation check. The confluent
didn't seem a bug but I couldn't see its intention.
> After digging around a bit, I realized that the problem is actually in
> nodeLockRows.c. It is supposed to do EvalPlanQualSetTuple(..., NULL)
> for each child table that's not supposed to return any row during the
> current EPQ test cycle. Unfortunately, it only does that reliably once
> the EPQ environment is already set up. If we discover we need an EPQ
> test while looking at a non-first child table, tables already passed
> over in the loop over node->lr_arowMarks don't get the word.
Thank you for the detailed explanation. I was wondering during
investigation about EvalPlanQualSetTuple(, NULL) was called only
for children after the first one that had EPQ test tuple. Now I
understand that it was the core of this bug.
> So the correct fix (or a correct fix, anyway; this could also have been
> done with more-invasive loop logic changes) is as attached. I'm working
> on back-patching this.
That really helps. Thank you.
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center
