Re: BUG: pg_class.relchecks overflow, making table undroppable - Mailing list pgsql-hackers

On Fri, 25 Sept 2026 at 11:05, Michael Paquier <michael@paquier.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)