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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: BUG #17994: Invalidating relcache corrupts tupDesc inside ExecEvalFieldStoreDeForm()
Дата
Msg-id 1742513.1688129204@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: BUG #17994: Invalidating relcache corrupts tupDesc inside ExecEvalFieldStoreDeForm()  (Andrew Dunstan <andrew@dunslane.net>)
Ответы Re: BUG #17994: Invalidating relcache corrupts tupDesc inside ExecEvalFieldStoreDeForm()  (Andrew Dunstan <andrew@dunslane.net>)
Список pgsql-bugs
Andrew Dunstan <andrew@dunslane.net> writes:
> On 2023-06-29 Th 18:41, Tom Lane wrote:
>> Why not make the hash key be the value
>> itself?  Wrap it in a bytea perhaps to avoid needing a bespoke
>> hash function.

> Not sure I understand.

Say the missingval for a particular column is text 'abc'.
We don't actually care which column it is, all we need is a
copy of that datum that will stay put for the rest of the
transaction.  So I'm thinking that the lookup key for the
hash table should actually be the contents of the datum,
and we don't need to store anything else at all.  (If we
happen to have two columns with the same missingval, they
can perfectly well share this hash entry.)  Then there's
no question of invalidation, or at least the existing
invalidation mechanisms for tupdescs do all we need.

            regards, tom lane



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

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: BUG #17994: Invalidating relcache corrupts tupDesc inside ExecEvalFieldStoreDeForm()
Следующее
От:
Дата:
Сообщение: BUG #18005: PSQL Process hangs in parallel mode / complement information