| From: | Andreas Karlsson <andreas(at)proxel(dot)se> |
|---|---|
| To: | vellaipandiyan sm <vellaipandiyan(dot)sm(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Review observations for partial REFRESH MATERIALIZED VIEW patc |
| Date: | 2026-05-19 09:59:54 |
| Message-ID: | 22b888d6-f941-407b-9776-f14f14510590@proxel.se |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 5/19/26 7:42 AM, vellaipandiyan sm wrote:
> 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.
Hi,
Thanks for the review, but please reply-all to the original thread when
you review a patch so the original author and previous reviewers can see
your review.
If you do not have the original email thread you can go into the archive
and request it to be sent to you so you can reply to it.
You can click the "Resend email" link at
https://www.postgresql.org/message-id/CAA4eK1KSEL%2Bb81L47MpdVCY79n0QgboxF6XTEjSc0ZcLkDzyWQ%40mail.gmail.com
--
Andreas Karlsson
Percona
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andreas Karlsson | 2026-05-19 10:04:39 | Re: Review observations for partial REFRESH MATERIALIZED VIEW patc |
| Previous Message | shveta malik | 2026-05-19 09:22:46 | Re: Improve conflict detection when replication origins are reused |