答复: questions about concurrency control in Postgresql

>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