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:alvherre@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
maybe 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
lockto 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