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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers