Hello hackers, 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. Thanks for working on this patch. Regards, Vellaipandiyan
