Re: Catalog Access (was: [GENERAL] Concurrency problem

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: Hannu Krosing <hannu(at)skype(dot)net>, Martijn van Oosterhout <kleptog(at)svana(dot)org>, "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>, Wes <wespvp(at)syntegra(dot)com>, Zeugswetter Andreas DCP SD <ZeugswetterA(at)spardat(dot)at>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Catalog Access (was: [GENERAL] Concurrency problem
Date: 2006-04-26 00:44:55
Message-ID: 10804.1146012295@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> Hannu Krosing wrote:
>> Would this take effect even inside a single command ? in other words, if
>> it were possible that an index appeared in middle of a big update, would
>> the tuples updated after the index becomes visible be also added to the
>> index ?

> This can't happen, because an UPDATE to a table requires acquiring a
> lock (RowExclusiveLock) which conflicts with a lock taken by the CREATE
> INDEX (ShareLock).

Right. By and large, schema-changing operations take AccessExclusive
lock on the table they are changing, which guarantees (a) no concurrent
operation is is touching the table, and (b) by the time the lock is
released, the schema-changing command is already committed and so its
catalog changes appear valid to any subsequent transactions touching the
table, since they look at the catalogs with SnapshotNow rules.

CREATE INDEX is the only schema-changing op that I can think of offhand
that takes a non-exclusive lock, and so its little problem with two
concurrent operations on the same table is unique.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2006-04-26 01:37:14 Re: Installation on Duel-Core Pentium XP
Previous Message Alvaro Herrera 2006-04-25 23:15:57 Re: ACL_CONNECT p.tch 6