Re: Refactoring SysCacheGetAttr to know when attr cannot be NULL

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Refactoring SysCacheGetAttr to know when attr cannot be NULL
Дата
Msg-id 2832011.1679800507@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Refactoring SysCacheGetAttr to know when attr cannot be NULL  (Justin Pryzby <pryzby@telsasoft.com>)
Список pgsql-hackers
Justin Pryzby <pryzby@telsasoft.com> writes:
> On Mon, Mar 13, 2023 at 02:19:07PM +0100, Daniel Gustafsson wrote:
>> +               elog(ERROR,
>> +                        "unexpected NULL value in cached tuple for pg_catalog.%s.%s",
>> +                        get_rel_name(cacheinfo[cacheId].reloid),

> Question: Is it safe to be making catalog access inside an error
> handler, when one of the most likely reason for hitting the error is
> catalog corruption ?

I don't see a big problem here.  If there were catalog corruption
preventing fetching the catalog's pg_class row, it's highly unlikely
that you'd have managed to retrieve a catalog row to complain about.
(That is, corruption in this particular catalog entry probably does
not extend to the metadata about the catalog containing it.)

> Maybe the answer is that it's not "safe" but "safe enough"

Right.

If we got concerned about this we could dodge the extra catalog access
by adding the catalog's name to CatCache entries.  I doubt it's worth
it though.  We can always re-evaluate if we see actual evidence of
problems.

            regards, tom lane



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

Предыдущее
От: Justin Pryzby
Дата:
Сообщение: Re: Refactoring SysCacheGetAttr to know when attr cannot be NULL
Следующее
От: Pavel Stehule
Дата:
Сообщение: Re: Schema variables - new implementation for Postgres 15