Re: Catalog Access (was: [GENERAL] Concurrency problem - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Catalog Access (was: [GENERAL] Concurrency problem
Date
Msg-id 10804.1146012295@sss.pgh.pa.us
Whole thread Raw
In response to Re: Catalog Access (was: [GENERAL] Concurrency problem  (Alvaro Herrera <alvherre@commandprompt.com>)
Responses Re: Catalog Access (was: [GENERAL] Concurrency problem  (Wes <wespvp@syntegra.com>)
List pgsql-hackers
Alvaro Herrera <alvherre@commandprompt.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


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: ACL_CONNECT p.tch 6
Next
From: Andrew Dunstan
Date:
Subject: Re: Installation on Duel-Core Pentium XP