Re: refresh materialized view concurrently

On Wed, Jul 3, 2013 at 10:47 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Wed, Jul 3, 2013 at 10:25 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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