varo 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'
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 黄晓骋 :
> From the above, I think the tuple lock is unnece
>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 wi
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 mean
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 an
