Re: Refactoring SysCacheGetAttr to know when attr cannot be NULL - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Refactoring SysCacheGetAttr to know when attr cannot be NULL
Date
Msg-id 2832011.1679800507@sss.pgh.pa.us
Whole thread Raw
In response to Re: Refactoring SysCacheGetAttr to know when attr cannot be NULL  (Justin Pryzby <pryzby@telsasoft.com>)
List 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 by date:

Previous
From: Justin Pryzby
Date:
Subject: Re: Refactoring SysCacheGetAttr to know when attr cannot be NULL
Next
From: Pavel Stehule
Date:
Subject: Re: Schema variables - new implementation for Postgres 15