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. Will
look at that later..
--
Michael
