Re: refresh materialized view concurrently

Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)com> wrote:
>> Other than these, I've found index is opened with NoLock,
>> relying on ExclusiveLock of parent matview, and ALTER INDEX SET
>> TABLESPACE or something similar can run concurrently, but it is
>> presumably safe.  DROP INDEX, REINDEX would be blocked by the
>> ExclusiveLock.
>
> I doubt very much that this is safe.  And even if it is safe
> today, I think it's a bad idea, because we're likely to try to
> reduce lock levels in the future.  Taking no lock on a relation
> we're opening, even an index, seems certain to be a bad idea.

What we're talking about is taking a look at the index definition
while the indexed table involved is covered by an ExclusiveLock.
Why is that more dangerous than inserting entries into an index
without taking a lock on that index while the indexed table is
covered by a RowExclusiveLock, as happens on INSERT?
RowExclusiveLock is a much weaker lock, and we can't add entries to
an index without looking at its definition.  Should we be taking
out locks on every index for every INSERT?  If not, what makes that
safe while merely looking at the definition is too risky?

--
Kevin Grittner
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company