Re: refresh materialized view concurrently

On Wed, Jul 3, 2013 at 10:47 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Wed, Jul 3, 2013 at 10:25 AM, Tom Lane <tgl@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  | tfoo      |
relation     | RowExclusiveLock | t         | virtualxid    | ExclusiveLock    | t         | transactionid |
ExclusiveLock   | t
 

No foo_pkey anywhere.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company