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: Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Sivaprasad <sivaprasad(dot)postgres(at)gmail(dot)com>
Subject: Re: BUG: pg_class.relchecks overflow, making table undroppable
Date: 2026-09-27 21:56:46
Message-ID: armRHds2MDhCUD2N@paquier.xyz
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Sep 25, 2026 at 02:33:57PM +0200, Matthias van de Meent wrote:
> 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.

That looks pretty good here, so applied and backpatched as the
consequences of keeping an overflowed counter can be really annoying.
--
Michael

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Chao Li 2026-09-27 22:46:50 Re: WAL segment file descriptor leak on read errors can PANIC the server
Previous Message Midhush Karthic 2026-09-27 21:41:01 [PATCH] Add target-column context for assignment coercion errors