Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nK16u-0003FA-4o for pgsql-bugs@arkaria.postgresql.org; Tue, 15 Feb 2022 16:55:28 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nK16t-0001pX-0g for pgsql-bugs@arkaria.postgresql.org; Tue, 15 Feb 2022 16:55:27 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nK16s-0001pL-P7 for pgsql-bugs@lists.postgresql.org; Tue, 15 Feb 2022 16:55:26 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nK16q-0001gg-Ae for pgsql-bugs@lists.postgresql.org; Tue, 15 Feb 2022 16:55:25 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 21FGtMxf3054064; Tue, 15 Feb 2022 11:55:22 -0500 From: Tom Lane To: Masahiko Sawada cc: Dmitry Koval , Dilip Kumar , andrewbille@gmail.com, PostgreSQL mailing lists Subject: Re: BUG #17385: "RESET transaction_isolation" inside serializable transaction causes Assert at the transaction end In-reply-to: References: <17385-9ee529fb091f0ce5@postgresql.org> <6e31c4ef-de9a-960b-1a21-e3b6ff0fa9c2@postgrespro.ru> <2733419.1644789029@sss.pgh.pa.us> <2778050.1644817168@sss.pgh.pa.us> Comments: In-reply-to Masahiko Sawada message dated "Wed, 16 Feb 2022 01:47:56 +0900" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3054062.1644944122.1@sss.pgh.pa.us> Date: Tue, 15 Feb 2022 11:55:22 -0500 Message-ID: <3054063.1644944122@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Masahiko Sawada writes: > It seems that we need another flag or a dedicated treatment for > transaction property GUCs. It effectively cannot change them within > the transaction regardless of SET, RESET, and RESET ALL, so I think we > can make it no-op (possibly with a notice). Yeah, I was considering that too. A new GUC_NO_RESET flag would be cheaper than running the check hooks during RESET, and probably safer too. On the other hand, we would lose the property that you can reset these settings as long as you've not yet taken a snapshot. I wonder whether there is any code out there that depends on that ... regards, tom lane