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

Hi,

On Fri, Sep 25, 2026 at 07:59:22AM +0900, Michael Paquier wrote:
> On Thu, Sep 24, 2026 at 07:03:45PM +0200, Matthias van de Meent wrote:
> > This causes various issues, such as possible WARNING spam to users
> > that need to load that relation into relcache, and an inability to
> > drop the relation because dropping the table requires the constraints
> > to be dropped first, and dropping a constraint decrements the counter
> > that has a check is in place to avoid the counter ever dropping below
> > zero (with an error if you try to decrement non-positive counter
> > values).
> >
> > I think we should forbid creating such large amounts of CHECK
> > constraints (as attached, backpatch-safe), or drop the "relchecks"
> > field wholesale/replace it with a 'haschecks' field.
> >
> > Also attached is an SQL script that shows the issue, and which doesn't
> > fail in the unsafe manner once PG is patched with the attached patch.
>
> Ahah, fun one! That's in the same line as the recent trigger fix in
> b99b74144f9f where catalogs could overflow. Even if it's something
> that people would not do in practice, this deserves a backpatch.

+1

Just a few comments:

=== 1

It needs a rebase due to 926627bf902

=== 2

+ ereport(ERROR,
+ errmsg("too many check constraints on relation \"%s\"",
+ RelationGetQualifiedRelationName(rel)));

I think ERRCODE_PROGRAM_LIMIT_EXCEEDED would be appropriate here?

=== 3

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.

Regards,

--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com