From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Amit Langote <amitlangote09(at)gmail(dot)com> |
Cc: | Justin Pryzby <pryzby(at)telsasoft(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: assert pg_class.relnatts is consistent |
Date: | 2020-02-13 16:04:03 |
Message-ID: | 27104.1581609843@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Amit Langote <amitlangote09(at)gmail(dot)com> writes:
> On Thu, Feb 13, 2020 at 4:51 PM Amit Langote <amitlangote09(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Emre Hasegeli | 2020-02-13 16:25:25 | Re: In PG12, query with float calculations is slower than PG11 |
Previous Message | Alvaro Herrera | 2020-02-13 15:47:54 | Re: Getting rid of some more lseek() calls |