Doubts about EvalPlanQual

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.

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

> 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.

But if the updater aborted, how can EvalPlanQual be called?
In this situation (updater aborted), EvalPlanQual's caller (such as
ExecUpdate and ExecDelete)
should get "HeapTupleMayBeUpdated", rather than "HeapTupleUpdated".

Am I right?

Jacky Leng wrote:
>> 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.
>
> But if the updater aborted, how can EvalPlanQual be called?
> In this situation (updater aborted), EvalPlanQual's caller (such as
> ExecUpdate and ExecDelete)
> should get "HeapTupleMayBeUpdated", rather than "HeapTupleUpdated".

Well, consider this update chain:

A -> B -> C

If A is the tuple visible to the snapshot of the updating query, and the
updater of (A->B) has committed, heap_update/delete call in
ExecUpdate/Delete will return HeapTupleUpdate.

Now that think about this more, I don't see either how that check in
EvalPlanQual could ever be true.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> writes:
> Now that think about this more, I don't see either how that check in
> EvalPlanQual could ever be true.

It's there primarily to make the tuple chain chasing code the same
as in other places. Whether it happens to be dead code today because of
arcane details of the usage of EvalPlanQual isn't very interesting.
(I'm unconvinced that it is dead code, but even if it is it'd be folly
to remove it.)

regards, tom lane

Tom Lane wrote:
> (I'm unconvinced that it is dead code, but even if it is it'd be folly
> to remove it.)

Agreed, it's a useful safeguard, even it it's a "can't happen" scenario.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

On 2/19/09, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
> Tom Lane wrote:
>> (I'm unconvinced that it is dead code, but even if it is it'd be folly
>> to remove it.)
>
> Agreed, it's a useful safeguard, even it it's a "can't happen" scenario.
>

if it is a "can't happen" scenario then why not make it an assert?

--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Asesoría y desarrollo de sistemas
Guayaquil - Ecuador
Cel. +59387171157

Jaime Casanova <jcasanov(at)systemguards(dot)com(dot)ec> writes:
> if it is a "can't happen" scenario then why not make it an assert?

Asserts on data-consistency checks aren't really a good idea.

(IOW this is "can't happen" only as long as your database isn't
corrupt...)

regards, tom lane

> Asserts on data-consistency checks aren't really a good idea.
>
> (IOW this is "can't happen" only as long as your database isn't
> corrupt...)
>

Then why not change this to an "ereport(PANIC ...)"?

Jacky Leng wrote:
>> Asserts on data-consistency checks aren't really a good idea.
>>
>> (IOW this is "can't happen" only as long as your database isn't
>> corrupt...)
>>
>
> Then why not change this to an "ereport(PANIC ...)"?

If you have a corrupted database, you want to be able to read it, not
panic. If anything, we could put a WARNING there, but I'm not 100% sure
it really is a "can't happen" case.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com