Hi, sending v2 to the list as well. This version changes the limit
check from `>=` to `>`, allowing the documented maximum of 32,767
CHECK constraints.
On Thu, Sep 24, 2026 at 10:34 PM Matthias van de Meent
<boekewurm+postgres(at)gmail(dot)com> wrote:
>
> Hi,
>
> There's probably no user that finds good use for this many check
> constraints, but users *can* create > 2^15 CHECK constraints on a
> table, and doing so will overflow the int16 (sqltype int2) column in
> which the relation's count of those is stored.
>
> 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.
>
> Note: the attached patch does not solve any issues in existing
> databases with overflowed relchecks fields.
>
>
> Kind regards,
>
> Matthias van de Meent
> Databricks (https://www.databricks.com)