Re: Refactoring SysCacheGetAttr to know when attr cannot be NULL
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Justin Pryzby <pryzby@telsasoft.com>
Cc: Daniel Gustafsson <daniel@yesql.se>,
Peter Eisentraut <peter.eisentraut@enterprisedb.com>,
pgsql-hackers@lists.postgresql.org
Date: 2023-03-26T03:15:07Z
Lists: 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
Commits
-
Add SysCacheGetAttrNotNull for guaranteed not-null attrs
- d435f15fff3c 16.0 landed