On 2013-07-03 11:08:32 -0400, Tom Lane wrote: > Robert Haas <robertmh...@gmail.com> writes: > > On Wed, Jul 3, 2013 at 10:47 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > >> Are we somehow not going through ExecOpenIndices? > > > I dunno. I just did a quick black-box test: > > > CREATE TABLE foo (a int primary key); > > BEGIN; > > INSERT INTO foo VALUES (1); > > SELECT relation::regclass, locktype, mode, granted FROM pg_locks; > > > I get: > > > relation | locktype | mode | granted > > ----------+---------------+------------------+--------- > > pg_locks | relation | AccessShareLock | t > > foo | relation | RowExclusiveLock | t > > | virtualxid | ExclusiveLock | t > > | transactionid | ExclusiveLock | t > > > No foo_pkey anywhere. > > That proves nothing, as we don't keep such locks after the query > (and there's no reason to AFAICS). See ExecCloseIndices.
Should be easy enough to test by hacking LOCK TABLE to lock indexes and taking out a conflicting lock (SHARE?) in a second transaction. I wonder if we shouldn't just generally allow that, I remember relaxing that check before (when playing with CREATE/DROP CONCURRENTLY afair). Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
