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.94.2) (envelope-from ) id 1tlVvp-00CcyB-NS for pgsql-bugs@arkaria.postgresql.org; Fri, 21 Feb 2025 16:31:17 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1tlVvn-00Ca8h-Vb for pgsql-bugs@arkaria.postgresql.org; Fri, 21 Feb 2025 16:31:15 +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.94.2) (envelope-from ) id 1tlVvn-00Ca5Q-LJ for pgsql-bugs@lists.postgresql.org; Fri, 21 Feb 2025 16:31:15 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1tlVvl-002BhK-1P for pgsql-bugs@lists.postgresql.org; Fri, 21 Feb 2025 16:31:15 +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 51LGV9Ys3137107; Fri, 21 Feb 2025 11:31:09 -0500 From: Tom Lane To: Laurenz Albe cc: =?ISO-8859-1?Q?=C1lvaro?= Herrera , Virender Singla , pgsql-bugs@lists.postgresql.org, Aniket Jha Subject: Re: Major Version Upgrade failure due to orphan roles entries in catalog In-reply-to: <58e47d097ed2a1512f47891293a7102d573fc970.camel@cybertec.at> References: <202502131716.7mgkcnrem2hn@alvherre.pgsql> <2939991.1740089974@sss.pgh.pa.us> <3073713.1740148903@sss.pgh.pa.us> <58e47d097ed2a1512f47891293a7102d573fc970.camel@cybertec.at> Comments: In-reply-to Laurenz Albe message dated "Fri, 21 Feb 2025 17:23:24 +0100" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3137105.1740155469.1@sss.pgh.pa.us> Date: Fri, 21 Feb 2025 11:31:09 -0500 Message-ID: <3137106.1740155469@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Laurenz Albe writes: > Thanks for the explanation. That might be worth a comment. The adjacent comment already says /* * Advance command counter so we can see new record; else tests in * AddRoleMems may fail. */ so I didn't see anything to add there. Maybe "We can skip this in cases where we will not call AddRoleMems"? Or maybe the better answer is to conclude that the whole idea of not calling CommandCounterIncrement unconditionally is too fragile and not worth expending brain cells on, and just rip out the if-test. regards, tom lane