Re: Rome university

From: Martijn van Oosterhout <kleptog(at)svana(dot)org>
To: letizia leo <letizia_leo(at)yahoo(dot)it>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Rome university
Date: 2006-05-02 22:00:38
Message-ID: 20060502220038.GG13702@svana.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, May 02, 2006 at 04:31:14PM +0200, letizia leo wrote:

<snip>
>
> and the doubt is the following: how is it possible that -line 144- Xmin
> is the current transaction ( i.e. it has created this tuple, it is
> holding an exclusive lock on it since it has not committed yet) and
> that
> -line 149- there is a different (?) transaction that is also locking
> the
> tuple (HEAP_IS_LOCKED=(HEAP_XMAX_EXCL_LOCK||HEAP_XMAX_SHARED_LOCK) )?

Are you considering READ COMMITTED access mode? There you can see
tuples added by commands that have not really committed.

> Unless we are missing something, this situation is possible exclusively
> in case the XMAX transaction is a subtransaction of XMIN, which can
> access the tuple despite the exclusive lock held by XMIN. This seems
> correct according to the comment in line 154, which refers to a
> "subtransaction".

I don't know much about this code, but at the very least it could be
there to check that what is in the xmax field is actually a real
transaction value and not a locking transaction... Future-proofing?

Hope this helps,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jim C. Nasby 2006-05-02 22:49:33 Re: patch review, please: Autovacuum/Vacuum times via stats.
Previous Message Alvaro Herrera 2006-05-02 21:48:37 Re: Rome university