From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Christopher Browne <cbbrowne(at)acm(dot)org> |
Cc: | pgsql-admin(at)postgresql(dot)org |
Subject: | Re: autovacuum |
Date: | 2006-02-04 19:12:07 |
Message-ID: | 20656.1139080327@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
Christopher Browne <cbbrowne(at)acm(dot)org> writes:
>> does autovacuum locks tables while vacuuming?
> Of course it does; any request to access a relation will issue one or
> more locks on the relation.
This is correct in general ...
> VACUUM issues an AccessShareLock request against each relation that is
> vacuumed, which is probably nearly the same lock request your
> applications will be requesting, save for the fact that they'll also
> be submitting some RowExclusiveLock requests for individual rows of
> relations.
... but wrong in detail. Actually VACUUM takes ShareUpdateExclusive
lock, which is a bit stronger than an ordinary reader's AccessShare
lock (it does not block ordinary reads or updates, but it does block
index creation as well as other attempts to VACUUM the table). Also,
RowExclusiveLock is a table-level lock. Data-modifying commands such
as UPDATE take RowExclusiveLock on the whole table as a means of letting
other sessions know that someone is changing the table. They also
take row-level locks on the specific rows they change.
This is all discussed here:
http://www.postgresql.org/docs/8.1/static/explicit-locking.html
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Mohan Anon | 2006-02-04 22:53:17 | Postgres 8.1.x and MIT Kerberos 5 |
Previous Message | Christopher Browne | 2006-02-04 14:54:30 | Re: autovacuum |