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 1wPHF4-000c85-38 for pgsql-hackers@arkaria.postgresql.org; Tue, 19 May 2026 10:00:03 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wPHF1-0045j2-1X for pgsql-hackers@arkaria.postgresql.org; Tue, 19 May 2026 10:00:00 +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 1wPHF1-0045it-0H for pgsql-hackers@lists.postgresql.org; Tue, 19 May 2026 10:00:00 +0000 Received: from smtp.outgoing.loopia.se ([93.188.3.37]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1wPHEz-00000000LrA-2LvU for pgsql-hackers@lists.postgresql.org; Tue, 19 May 2026 09:59:59 +0000 Received: from s807.loopia.se (localhost [127.0.0.1]) by s807.loopia.se (Postfix) with ESMTP id DBCBF5EB9A4 for ; Tue, 19 May 2026 11:59:55 +0200 (CEST) Received: from s981.loopia.se (unknown [172.22.191.5]) by s807.loopia.se (Postfix) with ESMTP id CD5BA5EA072; Tue, 19 May 2026 11:59:55 +0200 (CEST) Received: from localhost (unknown [172.22.191.5]) by s981.loopia.se (Postfix) with ESMTP id CA81F22B16E1; Tue, 19 May 2026 11:59:55 +0200 (CEST) X-Virus-Scanned: amavis at amavis.loopia.se X-Spam-Flag: NO X-Spam-Score: -1.2 X-Spam-Level: X-Spam-Status: No, score=-1.2 tagged_above=-999 required=6.2 tests=[ALL_TRUSTED=-1, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1] autolearn=disabled Authentication-Results: s473.loopia.se (amavis); dkim=pass (2048-bit key) header.d=proxel.se Received: from s899.loopia.se ([172.22.191.6]) by localhost (s473.loopia.se [172.22.190.13]) (amavis, port 10024) with UTF8LMTP id XaxNHMWIudRs; Tue, 19 May 2026 11:59:54 +0200 (CEST) X-Loopia-Auth: user X-Loopia-User: andreas@proxel.se X-Loopia-Originating-IP: 147.28.75.140 Received: from [192.168.0.121] (customer-147-28-75-140.stosn.net [147.28.75.140]) (Authenticated sender: andreas@proxel.se) by s899.loopia.se (Postfix) with ESMTPSA id 920CB2C8BA46; Tue, 19 May 2026 11:59:54 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proxel.se; s=loopiadkim1707418970; t=1779184794; bh=4cul5GDpYpuCvGRSNejiInOtE5wG8QMe3oW09K3lnKY=; h=Date:Subject:To:References:From:In-Reply-To; b=iTpsBxN6eEDxQiDGpNdyZnyVqt05nxb7N1X59KUeNbU2TixmeSAVX+6n5J39UJ9gw fCU4/av6nh/S4+GyPv5zfDZXrT1btNfLhByY9UVofYS9UBUwSraQnqVoAC8KbJo2pW 7we6GJvayGpdfnWOXZvE9TnH+K3GvzZSTeFXxe3SnrCrZOrw9ZO4bQtkzMnYF6HQ5Z 47Mszw5BsDMAxXNjW6Og62pgmc72RXohy3krJKukfFyJ1fG0W7TFESwkvKYUloI6Wc QOUU2hfacu1+7N/8RGJDgqlZbakhMZSQumZ5jP4xZgXrx/fdfOdIgrWXHs1wvbUa1g tIDZtooho7ixA== Message-ID: <22b888d6-f941-407b-9776-f14f14510590@proxel.se> Date: Tue, 19 May 2026 11:59:54 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Review observations for partial REFRESH MATERIALIZED VIEW patc To: vellaipandiyan sm , pgsql-hackers@lists.postgresql.org References: From: Andreas Karlsson Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk 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