Re: a few questions (and doubts) about xid

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: Luca Ferrari <fluca1978(at)infinito(dot)it>, pgsql-general(at)postgresql(dot)org
Subject: Re: a few questions (and doubts) about xid
Date: 2007-07-26 14:04:19
Message-ID: 26404.1185458659@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> 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.

Perhaps more accurately, a row that has been outdated (either replaced
by an updated version, or deleted) is also considered locked by the
Xmax transaction, until such time as that transaction commits or rolls
back. Other xacts that might want to modify the row have to wait for
the Xmax xact before they can know whether it's OK to modify or not.

The IS_LOCKED bit serves as a means of locking the row without actually
modifying it (yet). The locking semantics aren't really any different.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Richard Huxton 2007-07-26 14:04:35 Re: ssl connections to postgresql
Previous Message James B. Byrne 2007-07-26 13:26:01 Re: ssl connections to postgresql