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: Thu, 29 Jun 2023 16:30:21 -0400
Message-ID: <326723ee-ee05-35bf-06fd-e4f3afc61654@dunslane.net> (raw)
In-Reply-To: <1583514.1688066735@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>
On 2023-06-29 Th 15:25, Tom Lane wrote:
> Andrew Dunstan<andrew@dunslane.net> writes:
>> On 2023-06-29 Th 10:26, Tom Lane wrote:
>>> I'm a bit concerned about added
>>> overhead, and about whether the hashtable needs invalidation support.
>>> It might be better to key it off (relfilenode, attnum).
>> re relfilenode: we don't have it in getmissingattr, so that would
>> involve looking it up or whacking around the API.
> Yeah, I was afraid of that.
>
>> re invalidation: that seems to suggest that the missing value could
>> change under us. I don't think it can, but if it can then more than just
>> this is broken. If not, how would invalidation affect us?
> The scenario I'm afraid of is that we cache a missingval for table X,
> then X gets dropped, then a new table Y gets created that by bad luck
> has the same type OID as X did, then we add a column to Y that
> requires a missingval, and now we have an entry in the hashtable that
> matches Y but contains the wrong value. Admittedly, it seems very
> low probability that this would all happen within the span of one
> transaction, so maybe we can get away with ignoring the case. But
> if we used relfilenode, we'd have at least a little more protection
> because of the tombstone files that prevent immediate re-use of a
> relfilenode OID. I'm not sure that it'd be bulletproof even with
> relfilenode, though. Maybe we should bite the bullet and provide
> invalidation based on a pg_type inval callback.
>
>
Yeah, Robert has just convinced me, so I'll do it like that. It doesn't
look too hard.
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
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: <326723ee-ee05-35bf-06fd-e4f3afc61654@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