Re: BUG #17994: Invalidating relcache corrupts tupDesc inside ExecEvalFieldStoreDeForm()
От | Andrew Dunstan |
---|---|
Тема | Re: BUG #17994: Invalidating relcache corrupts tupDesc inside ExecEvalFieldStoreDeForm() |
Дата | |
Msg-id | 27522775-aa59-38d4-716e-c2de35bc3d5a@dunslane.net обсуждение исходный текст |
Ответ на | Re: BUG #17994: Invalidating relcache corrupts tupDesc inside ExecEvalFieldStoreDeForm() (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: BUG #17994: Invalidating relcache corrupts tupDesc inside ExecEvalFieldStoreDeForm()
|
Список | pgsql-bugs |
On 2023-07-10 Mo 15:51, Andres Freund wrote:
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.
How many times are people going to add a new column with a non-null default to a temp table? Usually you know the shape you want for a temp table when you create it, I should think. Even in a long-running pgbouncer session I wouldn't expect this to balloon substantially.
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.
OK, I'll send a revised patch.
cheers
andrew
-- Andrew Dunstan EDB: https://www.enterprisedb.com
В списке pgsql-bugs по дате отправления: