On Wed, Jul 3, 2013 at 10:47 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Robert Haas <robertmh...@gmail.com> writes:
>> On Wed, Jul 3, 2013 at 10:25 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>>> I don't believe that that happens. If it does, it's a bug. Either the
>>> planner or the executor should be taking a lock on each index touched
>>> by a query.
>
>> It seems Kevin's right. Not sure why that doesn't break.
>
> 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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
