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
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 |