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 1qOlpv-008stJ-Kb for pgsql-hackers@arkaria.postgresql.org; Wed, 26 Jul 2023 21:14:23 +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 1qOlpt-006IsR-Lj for pgsql-hackers@arkaria.postgresql.org; Wed, 26 Jul 2023 21:14:21 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qOlpt-006IsJ-CL for pgsql-hackers@lists.postgresql.org; Wed, 26 Jul 2023 21:14:21 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qOlpp-001jyX-Tm for pgsql-hackers@postgresql.org; Wed, 26 Jul 2023 21:14:20 +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 36QLE8Yf1948638; Wed, 26 Jul 2023 17:14:08 -0400 From: Tom Lane To: Nathan Bossart cc: Dagfinn Ilmari =?iso-8859-1?Q?Manns=E5ker?= , pgsql-hackers@postgresql.org Subject: Re: Obsolete reference to pg_relation in comment In-reply-to: <20230726205031.GD3310393@nathanxps13> References: <87sf9apnr0.fsf@wibble.ilmari.org> <20230726205031.GD3310393@nathanxps13> Comments: In-reply-to Nathan Bossart message dated "Wed, 26 Jul 2023 13:50:31 -0700" MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-ID: <1948636.1690406048.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Wed, 26 Jul 2023 17:14:08 -0400 Message-ID: <1948637.1690406048@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Nathan Bossart writes: > On Wed, Jul 26, 2023 at 06:48:51PM +0100, Dagfinn Ilmari Manns=C3=A5ker = wrote: >> * All accesses to pg_largeobject and its index make use of a single R= elation >> - * reference, so that we only need to open pg_relation once per transa= ction. >> + * reference, so that we only need to open pg_class once per transacti= on. >> * To avoid problems when the first such reference occurs inside a >> * subtransaction, we execute a slightly klugy maneuver to assign owne= rship of >> * the Relation reference to TopTransactionResourceOwner. > Hm. Are you sure this is actually referring to pg_class? It seems > unlikely given pg_relation was renamed 14 years before this comment was > added, and the code appears to be ensuring that pg_largeobject and its > index are opened at most once per transaction. I believe it is just a typo/thinko for pg_class, but there's more not to like about this comment. First, once we've made a relcache entry it would typically stay valid across uses, so it's far from clear that this coding actually prevents many catalog accesses in typical cases. Second, when we do have to rebuild the relcache entry, there's a lot more involved than just a pg_class fetch; we at least need to read pg_attribute, and I think there may be other catalogs that we'd read along the way, even for a system catalog that lacks complicated features. (pg_index would presumably get looked at, for instance.) I think we should reword this to just generically claim that holding the Relation reference open for the whole transaction reduces overhead. regards, tom lane