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@svana.org> http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to > litigate.
signature.asc
Description: Digital signature
