From 217dc525c08c2835f321ca45309601e8b1f57fec Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Fri, 8 Jan 2010 02:44:00 +0000 Subject: [PATCH] Fix oversight in EvalPlanQualFetch: after failing to lock a tuple because someone else has just updated it, we have to set priorXmax to that tuple's xmax (ie, the XID of the other xact that updated it) before looping back to examine the next tuple. Obviously, the next tuple in the update chain should have that XID as its xmin, not the same xmin as the preceding tuple that we had been trying to lock. The mismatch would cause the EvalPlanQual logic to decide that the tuple chain ended in a deletion, when actually there was a live tuple that should have been found. I inserted this error when recently adding logic to EvalPlanQual to make it lock tuples before returning them (as opposed to the old method in which the lock would occur much later, causing a great deal of work to be wasted if we only then discover someone else updated it). Sigh. Per today's report from Takahiro Itagaki of inconsistent results during pgbench runs. --- src/backend/executor/execMain.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/backend/executor/execMain.c b/src/backend/executor/execMain.c index 203ed8d928..8d7adfffbb 100644 --- a/src/backend/executor/execMain.c +++ b/src/backend/executor/execMain.c @@ -26,7 +26,7 @@ * * * IDENTIFICATION - * $PostgreSQL: pgsql/src/backend/executor/execMain.c,v 1.340 2010/01/06 03:04:01 momjian Exp $ + * $PostgreSQL: pgsql/src/backend/executor/execMain.c,v 1.341 2010/01/08 02:44:00 tgl Exp $ * *------------------------------------------------------------------------- */ @@ -1546,6 +1546,8 @@ EvalPlanQualFetch(EState *estate, Relation relation, int lockmode, { /* it was updated, so look at the updated version */ tuple.t_self = update_ctid; + /* updated row should have xmin matching this xmax */ + priorXmax = update_xmax; continue; } /* tuple was deleted, so give up */