Postgresql 刷新物化视图：并发、事务行为

关于的官方PostgreSQL 9.3文档尚未对其进行详细描述

引述如下：

Postgres 9.3中的物化视图有一个严重的限制，即在刷新时使用独占锁。这基本上阻止了在使用其父关系中的新数据刷新物化视图时读取该视图的任何尝试

另一个引用来自以下网站的帖子：

如果我理解正确，刷新物化视图将锁定 带有AccessExclusiveLock的物化视图，即使该视图已经 包含数据

我的问题：以下顺序正确吗：

查询正在访问物化视图

作业执行刷新物化视图。它会锁定视图，并等待使用matview的所有正在运行的查询完成

matview正在开始刷新；如果matview上有一个索引，它将同时更新（因此在一个事务中进行完全刷新）

使用matview的查询将等待刷新完成。如果这需要太长时间，则会出现类似“等待锁定超时错误”的情况

刷新完成后，锁被移除

正在等待matview的查询将继续

---

对答案持保留态度，因为我还没有研究过mat视图，但基于此：

它们背后的理念是将它们视为更聪明的

变体，将表创建为…

：

创建物化视图类似于创建表AS，只是它还记住了用于初始化视图的查询，以便以后可以根据需要刷新它。物化视图具有许多与表相同的属性，但不支持临时物化视图或自动生成OID

就我阅读

刷新物化视图

命令或我在其上找到的文档而言，它们不会自动更新，我对流程的理解与您相同

---

我想，排他锁来自这样一个事实，即您不容易知道（除了在琐碎的情况下）哪些行是脏的，哪些不是脏的。如果开发人员确定了一种有效的方法，那么物化视图可能会自动同时更新。

在Postgres 9.4发布时，情况并非完全如此。现在，您可以使用

同时刷新物化视图

命令同时刷新物化视图。从功能上讲，这会刷新视图，但不使用读取锁。就计算而言，这是一个更昂贵的操作，但是如果锁对你来说是一个问题（就像对我一样，它引导我走这条路），那么这不是一个坏方法

---

这里是发布说明中的一些更多信息：

是否有任何方法可以知道刷新何时完成，我想在刷新完成后触发与物化视图的联接面

并发刷新

应该锁定会话（因此它不是问题所建议的异步）

CUN当前

仅表示表未锁定。