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 1qFDWa-0000hC-Nq for pgsql-bugs@arkaria.postgresql.org; Fri, 30 Jun 2023 12:46:56 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1qFDWY-0000Yd-OO for pgsql-bugs@arkaria.postgresql.org; Fri, 30 Jun 2023 12:46:54 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qFDWY-0000YU-GW for pgsql-bugs@lists.postgresql.org; Fri, 30 Jun 2023 12:46:54 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qFDWV-001MZM-LT for pgsql-bugs@lists.postgresql.org; Fri, 30 Jun 2023 12:46:53 +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 35UCkiuB1742514; Fri, 30 Jun 2023 08:46:44 -0400 From: Tom Lane To: Andrew Dunstan cc: Andres Freund , exclusion@gmail.com, pgsql-bugs@lists.postgresql.org Subject: Re: BUG #17994: Invalidating relcache corrupts tupDesc inside ExecEvalFieldStoreDeForm() In-reply-to: <5316ba5d-ab3b-4ae2-6f6b-f22760932d99@dunslane.net> References: <17994-5c7100b51b4790e9@postgresql.org> <1306569.1687978174@sss.pgh.pa.us> <20230628194446.uu47f4vyfyjfl7dd@awork3.anarazel.de> <1314841.1687981948@sss.pgh.pa.us> <20230628205443.6gu5bmcck6t4pgyv@awork3.anarazel.de> <1509402.1688048784@sss.pgh.pa.us> <7ae37634-7626-8977-4d89-20603f0d1dcf@dunslane.net> <1583514.1688066735@sss.pgh.pa.us> <326723ee-ee05-35bf-06fd-e4f3afc61654@dunslane.net> <1610276.1688078516@sss.pgh.pa.us> <5316ba5d-ab3b-4ae2-6f6b-f22760932d99@dunslane.net> Comments: In-reply-to Andrew Dunstan message dated "Fri, 30 Jun 2023 08:11:27 -0400" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1742512.1688129204.1@sss.pgh.pa.us> Date: Fri, 30 Jun 2023 08:46:44 -0400 Message-ID: <1742513.1688129204@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Andrew Dunstan writes: > On 2023-06-29 Th 18:41, Tom Lane wrote: >> Why not make the hash key be the value >> itself? Wrap it in a bytea perhaps to avoid needing a bespoke >> hash function. > Not sure I understand. Say the missingval for a particular column is text 'abc'. We don't actually care which column it is, all we need is a copy of that datum that will stay put for the rest of the transaction. So I'm thinking that the lookup key for the hash table should actually be the contents of the datum, and we don't need to store anything else at all. (If we happen to have two columns with the same missingval, they can perfectly well share this hash entry.) Then there's no question of invalidation, or at least the existing invalidation mechanisms for tupdescs do all we need. regards, tom lane