| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com> |
| Cc: | Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: BUG: pg_class.relchecks overflow, making table undroppable |
| Date: | 2026-09-25 09:04:40 |
| Message-ID: | arY5KKfzODnXJ-eG@paquier.xyz |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Sep 25, 2026 at 08:41:38AM +0000, Bertrand Drouvot wrote:
> 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?
An error record would be appropriate, yes. That's reachable with SQL.
> 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.
Yeah, let's do that. That's unlikely but it would just be a waste and
that's just switching the order of things.
If somebody is willing to send an updated patch, feel free, I don't
have the energy for that today.. Jian also mentioned
pg_add_s16_overflow(), which is a good idea for this case. :D
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Nazir Bilal Yavuz | 2026-09-25 09:11:19 | Re: [PATCH] Fix TAP tests with recent IPC::Run on Windows |
| Previous Message | Andrew Bille | 2026-09-25 08:59:16 | [PATCH] Fix TAP tests with recent IPC::Run on Windows |