Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wPDEU-000Xtk-1C for pgsql-hackers@arkaria.postgresql.org; Tue, 19 May 2026 05:43:10 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wPDES-003r54-0v for pgsql-hackers@arkaria.postgresql.org; Tue, 19 May 2026 05:43:09 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wPDES-003r4w-04 for pgsql-hackers@lists.postgresql.org; Tue, 19 May 2026 05:43:08 +0000 Received: from mail-pl1-x631.google.com ([2607:f8b0:4864:20::631]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1wPDER-00000000JlE-0AsH for pgsql-hackers@lists.postgresql.org; Tue, 19 May 2026 05:43:08 +0000 Received: by mail-pl1-x631.google.com with SMTP id d9443c01a7336-2ba21d32776so22116575ad.2 for ; Mon, 18 May 2026 22:43:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1779169383; cv=none; d=google.com; s=arc-20240605; b=GG9To9Cffr/6wG4oeCbouOmZ5iLWKNefE0vdqYY46mtJdIG4NVTr6700hmuWmVdJ9M J+arJfhIYDi7t0TPSdMgoLQRKyMfPfWJDY/jUjjUJbWSAsSVWm55ArSizdBByv8u3Khr TzGoohu9gO5ZN0WNucGNe6wc9vEuAd29FyFULaqSyw8BR4Ixpxb4iTNyIJ72DTSbMVlW Xd0c21yYEVxK11Bb5uuhJlHGxPRQ2oyqrjEPQav1hqlmq6OGjBejUJ3tpQj5eVPtob3G tlqgqk3ivjHmAu+1ALnP4MFFrnbTJwN0ieQmGIshA4f0HKVzLlUYpd9VBrGh3/8QYq+9 3F1Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=to:subject:message-id:date:from:mime-version:dkim-signature; bh=+8YlQGGZo/35vHmQHobkVvUyEW9gkTYMTvfezPRJmpM=; fh=nwNxTtLLPTU0ewfLM7SSbrjMajMl+wwnFkCY/fi90vE=; b=aId//xXSHOeWOqs/Whhr2sZB+xXAoZmnhms9otrmYuqq5aqzWmWLtDEef3pTx7cC4S E4eLr7gaj6J9APMDjLp8rVhlNCNRSTQYB5QjRelC45qY6RDtlHTPeuFyStKWgUUHvWyp bCbRfsOaIRve26XfD2AMAz4Em4oGKHVa9fg+arbibXNYtkrf5f3JNRUh99bplLxSJ6cI zlb7ru3hKbwTpV+GvaIJmMDG/U58JygY6TDsvvG+AuQuTMpylLyZE8DwGeFZbGXlTUOK zoMxxUdZTtwE6VPQo6FyUq3wbbLzxqkBbnMQ00TDgckiZuKeof2sVYc+cb9pbyxrRV99 ueUw==; darn=lists.postgresql.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1779169383; x=1779774183; darn=lists.postgresql.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=+8YlQGGZo/35vHmQHobkVvUyEW9gkTYMTvfezPRJmpM=; b=BRUJG7PmtQ2P1fklX4EAkEeSU4mbfyWJxTzsxHHXFZ1Dpk7AL11PEG2rDDrzKJzHkk rTCisc83A6RA3wnAFYfo4c38aECX3eZwx17d/fjPINPqWX0Xlljv112O6IXX3o+htSsn FguqFyzMN6j+bOlOXwWwx2UbfQA9jYJCwojb7AHxpyKpASTajQ58ZHLd5CdzRNZNhUbB ql5Vw8+2CjRwijMzrjnLDlM593/YEeKYR9nQyii1Nd0fqAttP3/Z16F9wWGeL111pttK M7GS6wGrCbexr2jMxDTdcu2YYX8fQa6W7RcvpMIwm/WAVn5XvM5oQYIDVNuSYuef1qZi a0fQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779169383; x=1779774183; h=to:subject:message-id:date:from:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=+8YlQGGZo/35vHmQHobkVvUyEW9gkTYMTvfezPRJmpM=; b=DHrJnxJK1HyxsDLGnCiFqhj8J+yopaSxYrZbLBCi5UTYZzOSXBef3Mo7LiG081pcv+ u5gIWshBwb03kF3XGck1RQdJoZ2yV9ugKuRo4UcaWxMwN2+lYx0asqLb9GKma0i0nXsD xC1m1MSgJjdJ8P4ejL4LH1StZ+CYiE5v7hS8nBe8/7fY+3Nu0JgeYz3cwLJNFvmEYpQ3 nj4GM9XH/PctzQjQjyLgwUyHdsdna67cbNFsMgdc8L/SCZN4yLY6i/Afptqi8UYEonvk BAYqwz72I7yXaHbT+/UhB6kebpL04FHcDTWKDn0l7qJZj1cwinJ3vDaTJqXMRf+0a/gi vv6g== X-Gm-Message-State: AOJu0YxJXM3Spl7vrwkbtQHOZJEB6UcwwBkivmajzulGHjHOxJWs+RPE vWnIGCHbX+CqkzqVRGbcgRjCb6FynMK46u7SpsxBBeUZQOJRcsC3s+I848GV9+Sd30f2x8N7XG6 OPVTa0Azc20vIUTiEcyPCO6o3AZZAUnxDbrYAbP8= X-Gm-Gg: Acq92OHqW4zO3EoTZKVJLdiCkC0+lGab18WHs3aNxxr03544BRyBYlvkbNwOwLYVZHL pauzu0XycZU9AnuyOzkEsrH3+6fyfjPkXTicYKEyfmff/04omBc8NuxgcuQkPFGijAX+6fqaZFv qCJuF0fdcsjhMluhIDHIW9TfUnj+vGMWKPWLSs1FGDp+Kd17c85IizjXgSzfYSu/GsV05zg0O4Q JtSB+32zuadQW07XYxH8rgfANDARrxf3VjqMK+8mTPdjl9g0qdHh2cQstEvYj4RmZx8VFTFZX8d 2gaTf+HQTau9SnvjbIYSZFJOTB+ubcBYGADH3pn3 X-Received: by 2002:a17:902:d2c9:b0:2bd:b50f:c1bf with SMTP id d9443c01a7336-2bdb50fc703mr118067775ad.38.1779169382876; Mon, 18 May 2026 22:43:02 -0700 (PDT) MIME-Version: 1.0 From: vellaipandiyan sm Date: Tue, 19 May 2026 11:12:51 +0530 X-Gm-Features: AVHnY4J9ZjvpU8fMfUwFZSqWrTh7iJ6pGqP9Rr8HelNFy05TvGFVYZD95vTjgo4 Message-ID: Subject: Review observations for partial REFRESH MATERIALIZED VIEW patc To: pgsql-hackers@lists.postgresql.org Content-Type: multipart/alternative; boundary="0000000000000fc8dc0652252759" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000000fc8dc0652252759 Content-Type: text/plain; charset="UTF-8" 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 --0000000000000fc8dc0652252759 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hello hackers,

I reviewed the REFRESH MATERIALIZED VIEW ... WHER= E patch and had a few questions around concurrency semantics.

  • Th= e original DELETE -> INSERT approach exposing a consistency gap makes se= nse, especially once tuple locks disappear after DELETE. The newer FOR UPDA= TE + single-CTE approach seems safer, though I wonder whether overlapping r= efreshes could still encounter deadlock scenarios around UPSERT conflicts.<= /li>
  • The CONCURRENTLY behavior also feels somewhat unintuitive here. Wit= h WHERE refreshes, the non-CONCURRENT path appears more permissive for writ= ers than CONCURRENTLY WHERE, which seems opposite to the expectation establ= ished by normal REFRESH MATERIALIZED VIEW semantics.
  • It may also he= lp 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 refr= esh workloads.

Thanks for working on th= is patch.

Regards,

Vellaipandiyan

--0000000000000fc8dc0652252759--