From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Dunstan <andrew@dunslane.net>
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 15:25:35 -0400
Message-ID: <1583514.1688066735@sss.pgh.pa.us> (raw)
In-Reply-To: <7ae37634-7626-8977-4d89-20603f0d1dcf@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>
<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>
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.
regards, tom lane
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: tgl@sss.pgh.pa.us, andrew@dunslane.net, andres@anarazel.de, exclusion@gmail.com, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #17994: Invalidating relcache corrupts tupDesc inside ExecEvalFieldStoreDeForm()
In-Reply-To: <1583514.1688066735@sss.pgh.pa.us>
* 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