Horton

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

Richard Guo <guofenglinux@gmail.com>

View thread View on postgr.es
From: Richard Guo <guofenglinux@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>, kyzevan23@mail.ru, PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Date: 2022-07-29T16:24:06Z
Lists: pgsql-bugs 
On Fri, Jul 29, 2022 at 10:41 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:

> 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).


The patch looks good to me. Just wondering if there are any other types
of expressions that need to check for MaxTupleAttributeNumber in
parse_expr.c.

Thanks
Richard

Commits

  1. Check maximum number of columns in function RTEs, too.

  2. In transformRowExpr(), check for too many columns in the row.