pg.ddx.io pgsql-bugs@postgresql.org mailing list archive help / color / mirror / Atom feed From: Andrew Dunstan <andrew@dunslane.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andres Freund <andres@anarazel.de>
Cc: exclusion@gmail.com
Cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #17994: Invalidating relcache corrupts tupDesc inside ExecEvalFieldStoreDeForm()
Date: Fri, 30 Jun 2023 09:23:13 -0400
Message-ID: <cf24e075-0809-b9b8-4c73-48eed105b9a9@dunslane.net> (raw )
In-Reply-To: <1742513.1688129204@sss.pgh.pa.us >
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 >
<e52f6028-7196-8545-9726-a17a50ea14a3@dunslane.net >
<e6cbff03-32c3-4048-78b6-54d2907ba852@dunslane.net >
<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 >
<1742513.1688129204@sss.pgh.pa.us >
On 2023-06-30 Fr 08:46, Tom Lane wrote:
> Andrew Dunstan<andrew@dunslane.net> 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.
>
>
OK, I get it. Do we have a routine to wrap a Datum in a bytea, or do I
need to write one? It's slightly amusing that the original patch for
fast defaults stored the missing value as a bytea, but someone (Andres
IIRC) preferred that we store it as a one element array, so that's what
we went with.
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
view thread (33+ messages) latest in thread
Message-ID: <cf24e075-0809-b9b8-4c73-48eed105b9a9@dunslane.net>
Permalink: ../cf24e075-0809-b9b8-4c73-48eed105b9a9@dunslane.net/
Also on: postgresql.org/message-id/cf24e075-0809-b9b8-4c73-48eed105b9a9@dunslane.net
copy link · copy postgr.es
reply Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: andrew@dunslane.net, tgl@sss.pgh.pa.us, andres@anarazel.de, exclusion@gmail.com, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #17994: Invalidating relcache corrupts tupDesc inside ExecEvalFieldStoreDeForm()
In-Reply-To: <cf24e075-0809-b9b8-4c73-48eed105b9a9@dunslane.net>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox