I reviewed the REFRESH MATERIALIZED VIEW ... WHERE patch and had a few questions around concurrency semantics.
The original DELETE -> INSERT approach exposing a consistency gap makes sense, especially once tuple locks disappear after DELETE. The newer FOR UPDATE + single-CTE approach seems safer, though I wonder whether overlapping refreshes could still encounter deadlock scenarios around UPSERT conflicts.
The CONCURRENTLY behavior also feels somewhat unintuitive here. With WHERE refreshes, the non-CONCURRENT path appears more permissive for writers than CONCURRENTLY WHERE, which seems opposite to the expectation established by normal REFRESH MATERIALIZED VIEW semantics.
It may also help to document the intended guarantees around overlapping partial refreshes and concurrent DML on base tables.
Overall, the use case seems quite valuable for selective high-churn refresh workloads.
