Re: Refactoring SysCacheGetAttr to know when attr cannot be NULL

From: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
To: Daniel Gustafsson <daniel(at)yesql(dot)se>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Refactoring SysCacheGetAttr to know when attr cannot be NULL
Date: 2023-03-14 07:00:34
Message-ID: b289a570-2141-b3cf-0fff-ebcf1d0b28dc@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 13.03.23 14:19, Daniel Gustafsson wrote:
>> On 2 Mar 2023, at 15:44, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>
>> Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> writes:
>>> I think an error message like
>>> "unexpected null value in system cache %d column %d"
>>> is sufficient. Since these are "can't happen" errors, we don't need to
>>> spend too much extra effort to make it prettier.
>>
>> I'd at least like to see it give the catalog's OID. That's easily
>> convertible to a name, and it doesn't tend to move around across PG
>> versions, neither of which are true for syscache IDs.
>>
>> Also, I'm fairly unconvinced that it's a "can't happen" --- this
>> would be very likely to fire as a result of catalog corruption,
>> so it would be good if it's at least minimally interpretable
>> by a non-expert. Given that we'll now have just one copy of the
>> code, ISTM there's a good case for doing the small extra work
>> to report catalog and column by name.
>
> Rebased v3 on top of recent conflicting ICU changes causing the patch to not
> apply anymore. Also took another look around the tree to see if there were
> missed callsites but found none new.

I think the only open question here was the granularity of the error
message, which I think you had addressed in v2.

+ if (isnull)
+ {
+ elog(ERROR,
+ "unexpected NULL value in cached tuple for pg_catalog.%s.%s",
+ get_rel_name(cacheinfo[cacheId].reloid),
+ NameStr(TupleDescAttr(SysCache[cacheId]->cc_tupdesc,
attributeNumber - 1)->attname));
+ }

I prefer to use "null value" for SQL null values, and NULL for the C symbol.

I'm a bit hesitant about hardcoding pg_catalog here. That happens to be
true, of course, but isn't actually enforced, I think. I think that
could be left off. It's not like people will be confused about which
schema "pg_class.relname" is in.

Also, the cached tuple isn't really for the attribute, so maybe split
that up a bit, like

"unexpected null value in cached tuple for catalog %s column %s"

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Smith 2023-03-14 07:06:44 Re: Add macros for ReorderBufferTXN toptxn
Previous Message Amit Kapila 2023-03-14 06:50:14 Re: [PATCH] Use indexes on the subscriber when REPLICA IDENTITY is full on the publisher