Jacky Leng wrote:
> 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?
Tuples with an aborted xmin can be vacuumed right away. When we're
following the update chain in EvalPlanQual, it's possible that the
updater has aborted, the updated dead tuple is vacuumed away, and the
slot is reused for another unrelated tuple.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com