Prev: Streaming replication and non-blocking I/O
Next: [HACKERS] explain output infelicity in psql
From: =?UTF-8?B?6buE5pmT6aqL?= on 9 Dec 2009 02:33

>It's a two step process. An update marks the tuple locked. Another
>transaction which comes along and wants to lock the tuple waits on the
>transaction marked on the tuple. When the first transaction commits or
>aborts then the second transaction can proceed and lock the tuple
>itself.
I agree with it.

>The reason we need both locks is because the first transaction
>cannot go around the whole database finding every tuple it ever locked
>to unlock it, firstly that could be a very large list and secondly
>there would be no way to do that atomically.

You mean that 2PL is hard to realize actually, I agree too.
But it doesn't mean tuple lock is necessary.

>Tuple locks and all user-visible locks are indeed held until the end
>of the transaction.
I don't agree with it, for I see unlocktuple(...) in heap_update(...).

--Huang Xiaocheng
--Database & Information System Lab, Nankai University


__________ Information from ESET NOD32 Antivirus, version of virus signature database 4671 (20091208) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com



--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

 | 
Pages: 1
Prev: Streaming replication and non-blocking I/O
Next: [HACKERS] explain output infelicity in psql