From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: exclusion@gmail.com, pgsql-bugs@lists.postgresql.org, Andrew Dunstan <andrew@dunslane.net>
Subject: Re: BUG #17994: Invalidating relcache corrupts tupDesc inside ExecEvalFieldStoreDeForm()
Date: Wed, 28 Jun 2023 15:52:28 -0400
Message-ID: <1314841.1687981948@sss.pgh.pa.us> (raw)
In-Reply-To: <20230628194446.uu47f4vyfyjfl7dd@awork3.anarazel.de>
References: <17994-5c7100b51b4790e9@postgresql.org>
<1306569.1687978174@sss.pgh.pa.us>
<20230628194446.uu47f4vyfyjfl7dd@awork3.anarazel.de>
Andres Freund <andres@anarazel.de> writes:
> On 2023-06-28 14:49:34 -0400, Tom Lane wrote:
>> That's not sufficient lifespan in the scenario we're dealing
>> with here: if the tupdesc gets trashed anytime before the
>> eventual ExecEvalFieldStoreForm(), we'll have garbage in the
>> result tuple.
> What are the scenarios that could lead to the tupledesc being released before
> ExecEvalFieldStoreForm()? I guess a function call that does an ALTER TABLE
> might do the trick? But shouldn't such cases be prohibited by
> CheckTableNotInUse()?
Any old cache flush could do it; you don't need a local trigger event.
(Alexander's original test case uses CREATE PUBLICATION to trigger
the cache flush, but that's just an easy way to make it more-or-less
deterministic.)
> If other sessions caused the tupledesc to be changed,
> we should already hang onto the old definition via the
> RememberToFreeTupleDescAtEOX() mechanism?
I believe the tupdesc in question is actually in the typcache,
which doesn't have anything like RememberToFreeTupleDescAtEOX
(which is a horrid hack anyway if you ask me).
We could probably make things better for this specific case by
teaching the typcache not to replace a cached tupdesc unless its
contents actually change. But that just makes it harder to get
to a bug instance; it's not a cure-all.
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, andres@anarazel.de, andrew@dunslane.net
Subject: Re: BUG #17994: Invalidating relcache corrupts tupDesc inside ExecEvalFieldStoreDeForm()
In-Reply-To: <1314841.1687981948@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