Обсуждение: 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,
theslot must have been * recycled and reused for an unrelated tuple. This implies that * the latest version of the
rowwas deleted, so we need do * nothing. (Should be safe to examine xmin without getting * buffer's content lock,
sincexmin 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.linnakangas@enterprisedb.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.linnakangas@enterprisedb.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@systemguards.com.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