Re: [Bug] Duplicate results for inheritance and FOR UPDATE.

Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> writes:
> This issue is that some query returns duplicate rows after FOR
> UPDATE was blocked, in other words, after getting
> HeapTupleUpdated in ExecLockRows.

Good catch!

> 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 :-(.)

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.

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.

regards, tom lane