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
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
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
Hello,
I’m a student from Nankai University in China. Now I and my team do a
project which aims to integrate XML to Postgresql. What I do is to complete
the function of XML Update.
Now I’m researching in concurrency control. I have read the code about the
concurrency control for a long time
Hello,
I think in Postgresql, concurrency control acts like this:
tuple's infomask shows if it is being updated. If it is being updated now,
the latter transaction should reread the tuple and get the newer tuple.
During the progress of getting the newer tuple, it must use transaction
lock, I
