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