Re: BUG #17994: Invalidating relcache corrupts tupDesc inside ExecEvalFieldStoreDeForm()
От | Andrew Dunstan |
---|---|
Тема | Re: BUG #17994: Invalidating relcache corrupts tupDesc inside ExecEvalFieldStoreDeForm() |
Дата | |
Msg-id | 7dc0e894-62ff-381c-b633-fa68250dd586@dunslane.net обсуждение исходный текст |
Ответ на | Re: BUG #17994: Invalidating relcache corrupts tupDesc inside ExecEvalFieldStoreDeForm() (Alvaro Herrera <alvherre@alvh.no-ip.org>) |
Ответы |
Re: BUG #17994: Invalidating relcache corrupts tupDesc inside ExecEvalFieldStoreDeForm()
|
Список | pgsql-bugs |
On 2023-08-21 Mo 08:33, Alvaro Herrera wrote:
Hello, On 2023-Jul-12, Andrew Dunstan wrote:+ entry = hash_search(missing_cache, &key, HASH_ENTER, &found); + + if (!found) + { + /* cache miss, so we need a non-transient copy of the datum */ + oldctx = MemoryContextSwitchTo(TopMemoryContext); + entry->value = + datumCopy(attrmiss->am_value, false, att->attlen); + MemoryContextSwitchTo(oldctx); + }Hmm ... when exactly do these values get freed if no longer needed? Is the theory that leaking them is not relevant?
Not sure I understand "relevant" here. They don't get freed. There will be at most one entry per row in pg_attribute where atthasmissing is true. I originally suggested cleaning them up at transaction end, but there was an argument that that might not make them sufficiently long-lived, and I don't know of any time more coarse grained when we can conveniently clean them up.
cheers
andrew
-- Andrew Dunstan EDB: https://www.enterprisedb.com
В списке pgsql-bugs по дате отправления: