Rome university - Mailing list pgsql-hackers

From letizia leo
Subject Rome university
Date
Msg-id 20060502143114.4691.qmail@web86903.mail.ukl.yahoo.com
Whole thread Raw
Responses Re: Rome university
Re: Rome university
List 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 toprovide 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

pgsql-hackers by date:

Previous
From: Martijn van Oosterhout
Date:
Subject: Re: patch review, please: Autovacuum/Vacuum times via stats.
Next
From: Alvaro Herrera
Date:
Subject: Re: Rome university