Refresh materialized views: Concurrency, transactional behaviour

Question

The official PostgreSQL 9.3 documentation on REFRESH MATERIALIZED VIEW does not yet describe it in detail.

A quote from this blog:

materialize

Answer 1

Take the answer with a grain of salt, since I've yet to play around with mat views, but based on this:

http://www.postgresql.org/docs/current/static/sql-creatematerializedview.html

The philosophy behind them is to treat them like smarter variations of create table as ...:

CREATE MATERIALIZED VIEW is similar to CREATE TABLE AS, except that it also remembers the query used to initialize the view, so that it can be refreshed later upon demand. A materialized view has many of the same properties as a table, but there is no support for temporary materialized views or automatic generation of OIDs.

Insofar as I read the refresh materialized view command or the docs I've found on them, they don't get updated automatically, and I understand the flow the same way you do.

The exclusive lock, I imagine, comes from the fact that you can't easily know (except in trivial cases) which rows are dirty and which aren't. Had the devs identified an efficient way of doing so, the materialized view would probably be updating automatically and concurrently.