Re: questions about concurrency control in Postgresql

From: Daniel Farina <drfarina(at)gmail(dot)com>
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 06:01:04
Message-ID: 7b97c5a40912072201h6575201eid6597fc42052dd18@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2009/12/7 黄晓骋 <huangxclife(at)gmail(dot)com>:
> 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 XactLockTableWait(...).

That is a table lock...depending on the lock, other backends may be
allowed to update tuples in the relation still. Fine-grained tuple
locks are used to prevent unnecessary contention for a table-wide
lock.

See the documentation at the manual page:

http://www.postgresql.org/docs/8.4/static/explicit-locking.html

It gives a thorough treatment of table and row locking levels and
conflicts, as well as what gets what locks.

fdr

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2009-12-08 06:40:11 Re: WAL format
Previous Message Greg Smith 2009-12-08 05:05:33 Re: EXPLAIN BUFFERS