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

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: BUG #17994: Invalidating relcache corrupts tupDesc inside ExecEvalFieldStoreDeForm()
Дата
Msg-id 20230702221320.t2yr52ozuuzmhcdy@awork3.anarazel.de
обсуждение исходный текст
Ответ на Re: BUG #17994: Invalidating relcache corrupts tupDesc inside ExecEvalFieldStoreDeForm()  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: BUG #17994: Invalidating relcache corrupts tupDesc inside ExecEvalFieldStoreDeForm()  (Andrew Dunstan <andrew@dunslane.net>)
Список pgsql-bugs
Hi,

On 2023-07-02 17:57:03 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > Isn't that going to break the assumption that the key is unique within a
> > transaction?
> 
> Huh?  "abc" is "abc", no matter what.  At least if Andrew did what
> I suggested (I didn't look at the patch yet).

Yea, I think that was a brainfart after too briefly skimming the code.


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

.oO(Perhaps we need to add a boehm style GC ... No.)

Perhaps we could defer resetting the cache to when we're not inside a
procedure?

I kinda wonder if this isn't basically the start of a "string interning" style
infrastructure, except for more types than just strings... I've wondered about
having that quite a few times.

Greetings,

Andres Freund



В списке pgsql-bugs по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: BUG #17994: Invalidating relcache corrupts tupDesc inside ExecEvalFieldStoreDeForm()
Следующее
От: Thomas Munro
Дата:
Сообщение: Re: BUG #18009: Postgres Recovery not happening