Re: BUG #17994: Invalidating relcache corrupts tupDesc inside ExecEvalFieldStoreDeForm()
От | Andres Freund |
---|---|
Тема | Re: BUG #17994: Invalidating relcache corrupts tupDesc inside ExecEvalFieldStoreDeForm() |
Дата | |
Msg-id | 20230710195107.r4s3ig6llhy2j3zb@awork3.anarazel.de обсуждение исходный текст |
Ответ на | Re: BUG #17994: Invalidating relcache corrupts tupDesc inside ExecEvalFieldStoreDeForm() (Andrew Dunstan <andrew@dunslane.net>) |
Ответы |
Re: BUG #17994: Invalidating relcache corrupts tupDesc inside ExecEvalFieldStoreDeForm()
|
Список | 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
В списке pgsql-bugs по дате отправления: