Lists: | pgsql-hackers |
---|
From: | letizia leo <letizia_leo(at)yahoo(dot)it> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Rome university |
Date: | 2006-05-02 14:31:14 |
Message-ID: | 20060502143114.4691.qmail@web86903.mail.ukl.yahoo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
Hi,
We're a team from Rome University (Italy) and we are working on an
hacking of PostgreSQL MVCC. The basic idea is to have multiple
instances
of a same user transaction concurrently executing against the DB in
order to achieve fault tolerance. We do not want to bother you with the
details of our idea, but of course we'd be delighted to provide you
additional information wheter you were interested or even just curious!
We're writing to you since we're studying the current MVCC
implementation and we're stuck with a doubt that's driving us crazy
since a couple of weeks so we'd be extremely grateful to anybody who
could enlighten us.
Our amlethic question is:
tqual.c, HeapTupleSatisfies* (Self,Now etc). Let's focus on
HeapTupleSatisfiesItself for simplicity. The piece of code that's
unclear is the following:
144: else if (TransactionIdIsCurrentTransactionId(HeapTupleHeaderGetXmin(tuple)))
145: {
146: if (tuple->t_infomask & HEAP_XMAX_INVALID) /* xid invalid */
147: return true;
148:
149: if (tuple->t_infomask & HEAP_IS_LOCKED) /* not deleter */
150: return true;
151:
152: Assert(!(tuple->t_infomask & HEAP_XMAX_IS_MULTI));
153:
154: /* deleting subtransaction aborted? */
155: if (TransactionIdDidAbort(HeapTupleHeaderGetXmax(tuple)))
156: {
157: tuple->t_infomask |= HEAP_XMAX_INVALID;
158: SetBufferCommitInfoNeedsSave(buffer);
159: return true;
160: }
161:
162: Assert(TransactionIdIsCurrentTransactionId(HeapTupleHeaderGetXmax(tuple)));
163:
164: return false;
165: }
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) )?
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".
Are we understanding correctly what this code is doing and the related
underlying MVCC mechanisms?
Chiacchiera con i tuoi amici in tempo reale!
http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com
From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
---|---|
To: | letizia leo <letizia_leo(at)yahoo(dot)it> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Rome university |
Date: | 2006-05-02 21:48:37 |
Message-ID: | 20060502214837.GB18026@surnet.cl |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
letizia leo wrote:
> 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) )?
> 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.
Exactly.
> This seems correct according to the comment in line 154, which refers
> to a "subtransaction".
It is correct.
> Are we understanding correctly what this code is doing and the related
> underlying MVCC mechanisms?
Can't say, but that part at least you got right :-)
--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
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 |
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.