Re: assert pg_class.relnatts is consistent

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: assert pg_class.relnatts is consistent
Дата
Msg-id 27104.1581609843@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: assert pg_class.relnatts is consistent  (Amit Langote <amitlangote09@gmail.com>)
Ответы Re: assert pg_class.relnatts is consistent  (Amit Langote <amitlangote09@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: Getting rid of some more lseek() calls
Следующее
От: Emre Hasegeli
Дата:
Сообщение: Re: In PG12, query with float calculations is slower than PG11