Re: BUG: pg_class.relchecks overflow, making table undroppable

On Fri, 25 Sept 2026 at 11:05, Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>
> On Fri, Sep 25, 2026 at 08:41:38AM +0000, Bertrand Drouvot wrote:
> > Just a few comments:
> >
> > === 1
> >
> > It needs a rebase due to 926627bf902

Done

> > === 2
> >
> > + ereport(ERROR,
> > + errmsg("too many check constraints on relation \"%s\"",
> > + RelationGetQualifiedRelationName(rel)));
> >
> >
> > I think ERRCODE_PROGRAM_LIMIT_EXCEEDED would be appropriate here?

Done.

> > numchecks++;
> > +
> > + if (numchecks >= PG_INT16_MAX)
> > + ereport(ERROR,
> > + errmsg("too many check constraints on relation \"%s\"",
> > + RelationGetQualifiedRelationName(rel)));
> >
> > I wonder if it wouldn't make more sense to check numchecks >= PG_INT16_MAX before
> > calling StoreRelCheck()? That would avoid inserting the constraint, recording its
> > dependencies and invoking the post create hook for an object that will be rejected.
>
> Yeah, let's do that. That's unlikely but it would just be a waste and
> that's just switching the order of things.

Also done. Thanks for the fast replies.

Attached v3:

* Add errcode(PROGRAM_LIMIT_EXCEEDED) to the ereports.
* Use pg_add_s16_overflow() to detect the overflows.
This includes changing the type of local numchecks variables to
int16. SetRelationNumChecks's signature is unchanged.
* Move the overflow checks to before StoreRelCheck.
This saves one dirty tuple in catalog tables when that overflow happens.

Kind regards,

Matthias van de Meent
Databricks (https://www.databricks.com)