Re: BUG #17561: Server crashes on executing row() with very long argument list

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Cc: kyzevan23(at)mail(dot)ru, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #17561: Server crashes on executing row() with very long argument list
Date: 2022-07-29 14:40:55
Message-ID: 3768321.1659105655@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

I wrote:
> I think the parser should've prevented this. It's in charge of
> rejecting overlength SELECT lists, for example. Also, the limit
> probably needs to be just MaxTupleAttributeNumber.

Concretely, about as attached.

In the existing code, if you just supply 10000 or so columns you
reach this error in heaptuple.c:

if (numberOfAttributes > MaxTupleAttributeNumber)
ereport(ERROR,
(errcode(ERRCODE_TOO_MANY_COLUMNS),
errmsg("number of columns (%d) exceeds limit (%d)",
numberOfAttributes, MaxTupleAttributeNumber)));

I borrowed the errcode from that, but the wording from parse_node.c:

if (pstate->p_next_resno - 1 > MaxTupleAttributeNumber)
ereport(ERROR,
(errcode(ERRCODE_PROGRAM_LIMIT_EXCEEDED),
errmsg("target lists can have at most %d entries",
MaxTupleAttributeNumber)));

I'm a bit inclined to adjust parse_node.c to also use TOO_MANY_COLUMNS
(54011) instead of the generic PROGRAM_LIMIT_EXCEEDED (54000).

regards, tom lane

Attachment Content-Type Size
prevent-too-many-cols-in-ROW-expr.patch text/x-diff 837 bytes

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Richard Guo 2022-07-29 15:47:00 Re: BUG #17561: Server crashes on executing row() with very long argument list
Previous Message Tom Lane 2022-07-29 13:55:53 Re: BUG #17561: Server crashes on executing row() with very long argument list