Re: questions about concurrency control in Postgresql

From: Greg Stark <gsstark(at)mit(dot)edu>
To: 黄晓骋 <huangxclife(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: questions about concurrency control in Postgresql
Date: 2009-12-08 12:16:06
Message-ID: 407d949e0912080416vd8377c8pb6877d64254138fb@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2009/12/8 黄晓骋 <huangxclife(at)gmail(dot)com>:
> From the above, I think the tuple lock is unnecessary, because it uses
> transaction lock.
>
> Besides, tuple lock is unlocked after the tuple is updated but not after the
> transaction commits. I mean it's not 2PL.

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. 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.

Tuple locks and all user-visible locks are indeed held until the end
of the transaction.

--
greg

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Timothy Crouch 2009-12-08 13:14:12 Unsubscribe
Previous Message Heikki Linnakangas 2009-12-08 12:05:03 Re: Streaming replication, some small issues