From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
Cc: | Daniel Gustafsson <daniel(at)yesql(dot)se>, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Refactoring SysCacheGetAttr to know when attr cannot be NULL |
Date: | 2023-03-26 03:15:07 |
Message-ID: | 2832011.1679800507@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Justin Pryzby <pryzby(at)telsasoft(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2023-03-26 06:53:49 | Re: Schema variables - new implementation for Postgres 15 |
Previous Message | Justin Pryzby | 2023-03-26 02:59:49 | Re: Refactoring SysCacheGetAttr to know when attr cannot be NULL |