答复: questions about concurrency control in Postgresql
От | 黄晓骋 |
---|---|
Тема | 答复: questions about concurrency control in Postgresql |
Дата | |
Msg-id | 002101ca78a1$f2e433f0$d8ac9bd0$@com обсуждение исходный текст |
Ответ на | Re: questions about concurrency control in Postgresql (Greg Stark <gsstark@mit.edu>) |
Список | pgsql-hackers |
>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
В списке pgsql-hackers по дате отправления: