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 1ocfXo-0006si-Ol for pgsql-bugs@arkaria.postgresql.org; Mon, 26 Sep 2022 04:16:36 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1ocfXm-0000Yv-3T for pgsql-bugs@arkaria.postgresql.org; Mon, 26 Sep 2022 04:16:34 +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 1ocfXl-0000WY-RL for pgsql-bugs@lists.postgresql.org; Mon, 26 Sep 2022 04:16:33 +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 1ocfXe-00043X-3X for pgsql-bugs@lists.postgresql.org; Mon, 26 Sep 2022 04:16:30 +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 28Q4GOYj3269451; Mon, 26 Sep 2022 00:16:24 -0400 From: Tom Lane To: Michael Paquier cc: Masahiko Sawada , Justin Pryzby , Dmitry Koval , Dilip Kumar , andrewbille@gmail.com, pgsql-bugs@lists.postgresql.org, Kyotaro Horiguchi Subject: Re: BUG #17385: "RESET transaction_isolation" inside serializable transaction causes Assert at the transaction end In-reply-to: References: <20220628003720.GG19662@telsasoft.com> <2604497.1664053071@sss.pgh.pa.us> Comments: In-reply-to Michael Paquier message dated "Mon, 26 Sep 2022 12:40:55 +0900" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3269449.1664165784.1@sss.pgh.pa.us> Date: Mon, 26 Sep 2022 00:16:24 -0400 Message-ID: <3269450.1664165784@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk [ hit send too soon ... ] Michael Paquier writes: > On Sat, Sep 24, 2022 at 04:57:51PM -0400, Tom Lane wrote: >> 0002 seems quite invasive and hard to review compared to what it >> accomplishes. > 0002 is not that confusing to me: the units are moved to be first and > to use the first flag bytes, while the more conceptual flags are moved > to be always after. Yeah, but why? I see no good reason why those fields need to be first. > I would have reorganized a bit more the > description flags, TBH. Looking at it closer, I agree that GUC_EXPLAIN and GUC_RUNTIME_COMPUTED should be moved to be with the other non-units flags. But I don't see why we need to re-order the entries more than that. I'm concerned for one thing that the order of the entries in this list stay comparable to the order in which the flags are dealt with in other code, such as pg_settings_get_flags or the guc_tables.c entries. regards, tom lane