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()
In-reply-to: <20230628194446.uu47f4vyfyjfl7dd@awork3.anarazel.de>
References: <17994-5c7100b51b4790e9@postgresql.org>
 <1306569.1687978174@sss.pgh.pa.us>
 <20230628194446.uu47f4vyfyjfl7dd@awork3.anarazel.de>
Comments: In-reply-to Andres Freund <andres@anarazel.de>
	message dated "Wed, 28 Jun 2023 12:44:46 -0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1314840.1687981948.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Wed, 28 Jun 2023 15:52:28 -0400
Message-ID: <1314841.1687981948@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1314841.1687981948%40sss.pgh.pa.us>
Precedence: bulk

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 b=
efore
> ExecEvalFieldStoreForm()? I guess a function call that does an ALTER TAB=
LE
> 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