Re: assert pg_class.relnatts is consistent

From: Justin Pryzby <pryzby(at)telsasoft(dot)com>
To: Amit Langote <amitlangote09(at)gmail(dot)com>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: assert pg_class.relnatts is consistent
Date: 2020-02-13 08:11:45
Message-ID: 20200213081145.GA1412@telsasoft.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Feb 13, 2020 at 04:51:01PM +0900, Amit Langote wrote:
> On Thu, Feb 13, 2020 at 3:23 AM Justin Pryzby <pryzby(at)telsasoft(dot)com> wrote:
> > Forking this thread for two tangential patches which I think are more
> > worthwhile than the original topic's patch.
> > https://www.postgresql.org/message-id/20200207143935.GP403%40telsasoft.com
> >
> > Is there a better place to implement assertion from 0002 ?
>
> I would think the answer to that would be related to the answer of why
> you think we need this assert in the first place?
>
> 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?

Right. If adding or removing a column from pg_class (or others) it's necessary
not only to add the column in the .h file, and update references like Anum_*,
but also to update that catalog's own pg_class.relnatts in pg_class.dat.

On the other thead, Alvaro agreed it might be worth experimenting with moving
"indisclustered" from boolean in pg_index to an Oid in pg_class. There's not
many references to it, so I was able to make most of the necessary changes
within an hour .. but spent some multiple of that tracing the crash in initdb,
which I would prefer to have failed less obscurely.

--
Justin

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Langote 2020-02-13 08:12:48 Re: assert pg_class.relnatts is consistent
Previous Message Michael Paquier 2020-02-13 08:10:12 Re: assert pg_class.relnatts is consistent