Luca Ferrari wrote:
> On Wednesday 25 July 2007 Gregory Stark's cat, walking on the keyboard, wrote:
> > If you really want to understand how snapshots work at this level you could
> > read (slowly -- it's pretty dense stuff) through
> > src/backend/utils/time/tqual.c:HeapTupleSatisfiesMVCC()
>
> Ok, I need a little hint here:
>
> if (tuple->t_infomask & HEAP_XMAX_COMMITTED)
> {
> if (tuple->t_infomask & HEAP_IS_LOCKED)
> return true;
> return false;
> }
>
> if the tuple xmin has committed and the xmax is also committed the tuple is
> not visible (return false). But if it is locked then the tuple is visible.
> Now htup.h says that if the tuple is locked it has not been really deleted by
> xmax, but only locked. Does this means that xmax is going to release locks?
> In other words the tuple will not be visible while it is locked, even if the
> xmax has committed but still not released the locks? Is this a situation due
> to a delay between the commit and the lock release?
What's going on here is that we use Xmax not only for storing "this
transaction deleted the row" but also for storing "this transaction
locked the row". So the row is not really deleted at all. The
IS_LOCKED bit tells you whether the row is locked or deleted when the
Xmax is set.
Of course, a locked row cannot be deleted. When you want to delete a
row that you have previously locked, you reset the IS_LOCKED bit.
--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
