You are right. I never consider the SELECT FOR UPDATE/SHARE type queries, so I got the wrong conclusion. I have seen the content in the comment of heap_lock_tuple().
Thank you, Best Regards, --Huang Xiaocheng --Database & Information System Lab, Nankai University -----邮件原件----- 发件人: Alvaro Herrera [mailto:alvhe...@commandprompt.com] 发送时间: 2009年12月10日 22:54 收件人: 黄晓骋 抄送: 'Greg Stark'; pgsql-hackers@postgresql.org 主题: Re: [HACKERS] 答复: questions about concurrency control in Postgresql 黄晓骋 escribió: > 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. Actually it's the buffer lock that's used to protect most of infomask. Tuple locks are only used while XMAX and some infomask bits are set for SELECT FOR UPDATE/SHARE type queries. That can take a while because it may need I/O in pg_multixact, so the buffer lock is not appropriate to hold for so long. -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. __________ Information from ESET NOD32 Antivirus, version of virus signature database 4677 (20091210) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __________ Information from ESET NOD32 Antivirus, version of virus signature database 4687 (20091214) __________ 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
