加concurrently是唯一避免读锁的方案，但必须显式创建覆盖全部分组列且全为not null的unique索引，缺一则立即报错“does not have a unique index”，且刷新仍可能因唯一键冲突或行被更新而失败。
REFRESH MATERIALIZED VIEW CONCURRENTLY 直接报错：没有唯一索引
这不是配置或权限问题，是硬性前提——命令根本不会开始执行，只要物化视图上没建满足条件的唯一索引，就会立刻失败，错误信息固定为：ERROR: cannot refresh materialized view "xxx" concurrently, because it does not have a unique index。
必须手动在物化视图上显式创建：CREATE UNIQUE INDEX（不能依赖源表主键，也不能靠 UNIQUE CONSTRAINT 自动带出索引）；索引列全部需为 NOT NULL；若物化视图含 GROUP BY a, b，索引必须包含 (a, b) 全部分组列。
- 刚建完索引可能状态是
INVALID，需等一次VACUUM或ANALYZE后才被CONCURRENTLY识别 - 表达式索引（如
(UPPER(name))）、带WHERE条件的索引、函数索引，一律不被接受 - 物化视图处于
WITH NO DATA状态（空壳）时，CONCURRENTLY也会拒绝执行——必须先用普通REFRESH填充一次
刷新期间唯一键冲突或行被业务更新导致中途失败
CONCURRENTLY 不是“无感更新”，它会在最后 merge 阶段尝试对旧行加锁并执行 INSERT/UPDATE/DELETE。此时若业务写入与新数据产生冲突，会直接中断刷新。
- 新数据中某行的唯一键（如
order_id）已由业务 INSERT 或 UPDATE 写入，触发ERROR: duplicate key value violates unique constraint - 某行在 merge 前刚被业务 UPDATE 过，导致
could not lock updated tuple in materialized view - 这类失败不会回滚中间状态，物化视图可能处于部分更新、部分未更新的混合状态
物化视图定义本身就不支持并发刷新
即使索引建对了，某些定义结构会让 PostgreSQL 主动拒绝 CONCURRENTLY，因为它无法保证两次查询结果可比。
- 定义中含不可重放表达式：如
now()、random()、current_user等 - 含窗口函数（
ROW_NUMBER()、RANK()）或DISTINCT ON，且未配ORDER BY显式保证顺序 - 聚合视图中使用了非确定性函数（如
json_agg不带ORDER BY），导致新旧数据行无法精确匹配
磁盘空间不足或锁等待被误判为“刷新失败”
报错未必是 SQL 语法或逻辑问题，更可能是资源层面卡住，但错误信息不直观。
- 每次
CONCURRENTLY刷新都会生成临时副本，占用额外磁盘空间；高频刷新（如每分钟）容易撑爆pg_wal或base目录，最终表现为no space left on device - 它仍持有
SHARE UPDATE EXCLUSIVE锁，如果此时有其他会话正执行ALTER MATERIALIZED VIEW或DROP INDEX，当前刷新会被阻塞在锁等待，超时后可能显示为“失败”而非“等待” - 查
pg_stat_activity，若wait_event_type = 'Lock'且state = 'active'，说明不是代码错，是锁竞争
CONCURRENTLY 就可能在比对阶段静默退出——它不报明确错误，只留一个不一致的结果。
