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

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: BUG: pg_class.relchecks overflow, making table undroppable
Date: 2026-09-24 22:59:22
Message-ID: arWrSl3XON1pTGNp@paquier.xyz
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Nikhil Kumar Veldanda 2026-09-24 23:00:29 Re: ZSTD TOAST compression, and an extensible compression method encoding
Previous Message Masahiko Sawada 2026-09-24 22:08:40 Re: Fix "unexpected logical decoding status change" error; from concurrent logical decoding activation