I think I know why we need tuple lock. Though we have tuple's infomask shows whether the tuple is being updated, before we set the tuple's infomask, there may be two transaction coming and updating the tuple. They both think the tuple is ok to be updated, and then it's wrong. In PostgreSQL, we can use buffer lock to solve the problem , but its granularity is not proper. So we must use tuple lock to solve the problem. Thank you, Greg. You prompt me to think clearly about it. Happy communicating with you, and thanks again.
--Huang Xiaocheng --Database & Information System Lab, Nankai University -----邮件原件----- 发件人: gsst...@gmail.com [mailto:gsst...@gmail.com] 代表 Greg Stark 发送时间: 2009年12月8日 20:16 收件人: 黄晓骋 抄送: pgsql-hackers@postgresql.org 主题: Re: questions about concurrency control in Postgresql 2009/12/8 黄晓骋 <huangxcl...@gmail.com>: > From the above, I think the tuple lock is unnecessary, because it uses > transaction lock. > > Besides, tuple lock is unlocked after the tuple is updated but not after the > transaction commits. I mean it's not 2PL. 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. 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. Tuple locks and all user-visible locks are indeed held until the end of the transaction. -- greg __________ Information from ESET NOD32 Antivirus, version of virus signature database 4671 (20091208) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __________ Information from ESET NOD32 Antivirus, version of virus signature database 4674 (20091209) __________ 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
