Re: BUG #17994: Invalidating relcache corrupts tupDesc inside ExecEvalFieldStoreDeForm()

From: Andres Freund <andres(at)anarazel(dot)de>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, exclusion(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #17994: Invalidating relcache corrupts tupDesc inside ExecEvalFieldStoreDeForm()
Date: 2023-07-10 19:51:07
Message-ID: 20230710195107.r4s3ig6llhy2j3zb@awork3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Hi,

On 2023-07-08 08:48:00 -0400, Andrew Dunstan wrote:
> On 2023-07-02 Su 22:15, Andrew Dunstan wrote:
> > > > > Separately, will this work correctly with procedures keeping values alive
> > > > > across transactions?
> > > > That might be an issue. But couldn't we make this cache just live for
> > > > the life of the process? It's unlikely to get large.
> > > I don't have a good handle about how big it'd end up being in some of the less
> > > common workloads. I can imagine workloads with temp tables or such churning
> > > through a lot of default values - often the "keyed by value" approach will
> > > save the day, but I imagine not always.
> >
> > The maximum number of entries in the table is the number of pg_attribute
> > rows with atthasmissing = true and attbyval = false. In practice I
> > suspect that's mostly going to be fairly low.

It's not really bound by that, because the set of rows can change over
time. Particularly with temp tables.

> The thread seems to have died down a bit. Do we have a consensus on Tom's
> approach?

I guess so. It's far from pretty, but nobody really has come up with something
better.

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Noah Misch 2023-07-10 20:00:12 Re: BUG #17928: Standby fails to decode WAL on termination of primary
Previous Message Gurjeet Singh 2023-07-10 16:43:49 Re: BUG #18016: REINDEX TABLE failure