>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@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
