From: | Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> |
---|---|
To: | tgl(at)sss(dot)pgh(dot)pa(dot)us |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [Bug] Duplicate results for inheritance and FOR UPDATE. |
Date: | 2014-12-12 01:23:56 |
Message-ID: | 20141212.102356.73006940.horiguchi.kyotaro@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2014-12-12 01:31:33 | Re: Proposal : REINDEX SCHEMA |
Previous Message | Simon Riggs | 2014-12-12 01:19:59 | Re: Proposal : REINDEX SCHEMA |