Doubts about EvalPlanQual

From: "Jacky Leng" <lengjianquan(at)163(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Doubts about EvalPlanQual
Date: 2009-02-19 05:24:31
Message-ID: gniqee$18cb$1@news.hub.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

When I read function "EvalPlanQual", I found the following code:

if (heap_fetch(relation, &SnapshotDirty, &tuple, &buffer, true, NULL))
{
/*
* If xmin isn't what we're expecting, the slot must have been
* recycled and reused for an unrelated tuple. This implies that
* the latest version of the row was deleted, so we need do
* nothing. (Should be safe to examine xmin without getting
* buffer's content lock, since xmin never changes in an existing
* tuple.)
*/
if (!TransactionIdEquals(HeapTupleHeaderGetXmin(tuple.t_data),
priorXmax))
{
ReleaseBuffer(buffer);
return NULL;
}

AFAICS, when Vacuum decides to reclaim any version V of a tuple T, there
must be none concurrent transactions that are accessing or will access any
versions before V, because HeapTupleSatisfiesVacuum ensures this.

If I'm right, then my doubt is: how can the branch "if
(!TransactionIdEquals(HeapTupleHeaderGetXmin(tuple.t_data), priorXmax))"
happen? Is this a dead branch?

If not, can anyone give an example to explain how does this happen?

Thanks a lot.

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2009-02-19 07:35:14 Re: Re: [COMMITTERS] pgsql: Start background writer during archive recovery.
Previous Message Robert Haas 2009-02-19 04:28:02 Re: Proposed Patch to Improve Performance of Multi-BatchHash Join for Skewed Data Sets