Re: BUG #19627: 32,768 trigger arguments wrap `tgnargs` and are silently lost at runtime

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

In response to

Responses

Browse pgsql-bugs by date

  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