| From: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
|---|---|
| To: | v3rdant(dot)xiang(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Subject: | Re: BUG #19627: 32,768 trigger arguments wrap `tgnargs` and are silently lost at runtime |
| Date: | 2026-08-19 02:56:36 |
| Message-ID: | 20260819.115636.1952223713943679969.horikyota.ntt@gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
At Tue, 18 Aug 2026 09:33:12 +0000, PG Bug reporting form <noreply(at)postgresql(dot)org> wrote in
> `CREATE TRIGGER` accepts 32,768 arguments, builds and stores the complete
> `tgargs` payload, but narrows the list length from `int` to `int16` without
> a
> limit check. The catalog stores `tgnargs = -32768`.
...
> ## Affected version
>
> Reproduced twice on PostgreSQL 18.4 Debug and twice on optimized Release.
> The
> checked current source still assigns `list_length(stmt->args)` directly to
> an
> `int16`.
I think that's correct. Since list_length() returns an int here, I
think it is sufficient to simply make nargs an int so that we can
check the upper limit. It would also be possible to increase the
limit, but this patch simply enforces the current internal limit. The
error message follows the one used in AggregateCreate().
The same code goes back at least to PostgreSQL 14, and the attached
patch can be applied as-is to all versions since then.
Regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center
| Attachment | Content-Type | Size |
|---|---|---|
| v1-0001-Reject-too-many-arguments-in-CREATE-TRIGGER.patch | text/x-patch | 1.3 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | PG Bug reporting form | 2026-08-19 03:50:55 | BUG #19629: pg_restore_relation_stats reports XX000 instead of proper SQLSTATE for input validation errors |
| Previous Message | Tender Wang | 2026-08-19 02:28:20 | Re: BUG #19626: Segmentation fault planning self-join IN subquery with LATERAL UNION ALL |