Re: assert pg_class.relnatts is consistent - Mailing list pgsql-hackers

From Tom Lane
Subject Re: assert pg_class.relnatts is consistent
Date
Msg-id 27104.1581609843@sss.pgh.pa.us
Whole thread Raw
In response to Re: assert pg_class.relnatts is consistent  (Amit Langote <amitlangote09@gmail.com>)
Responses Re: assert pg_class.relnatts is consistent
List pgsql-hackers
Amit Langote <amitlangote09@gmail.com> writes:
> On Thu, Feb 13, 2020 at 4:51 PM Amit Langote <amitlangote09@gmail.com> wrote:
>> I know I have made the mistake of not updating relnatts when I added
>> relispartition, etc. to pg_class, only to be bitten by it in the form
>> of seemingly random errors/crashes.  Is that why?

> Sorry for not having read the patch properly.
>> +     /* Check that pg_class data is consistent now, rather than failing obscurely later */
> That seems to be it.

I've been burnt by this too :-(.  However, I think this patch is
completely the wrong way to go about improving this.  What we should
be doing, now that we have all that perl code generating postgres.bki,
is eliminating the problem at the source.  That is, drop the hand-coded
relnatts values from pg_class.dat altogether, and let the perl code fill
it in --- compare the handling of pg_proc.pronargs for instance.

(While we're at it, an awful lot of the bulk of pg_class.dat could be
replaced by BKI_DEFAULT() entries in pg_class.h, though I'm less sure
that that's much of an improvement.  I think we intentionally didn't
bother when we put in the BKI_DEFAULT support, reasoning that there
were too few pg_class.dat entries to bother.)

            regards, tom lane



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Getting rid of some more lseek() calls
Next
From: Emre Hasegeli
Date:
Subject: Re: In PG12, query with float calculations is slower than PG11