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

From: Richard Guo <guofenglinux(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, kyzevan23(at)mail(dot)ru, PostgreSQL mailing lists <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 15:47:00
Message-ID: CAMbWs4_wzOXFuK1xtHPHLiN5LvvhxzbTBeRBZ7jisL7aznALhg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Fri, Jul 29, 2022 at 9:56 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> writes:
> > On 2022-Jul-29, PG Bug reporting form wrote:
> >> When executing the following query:
> >> (echo "SELECT row("; for ((i=1;i<100001;i++)); do echo "'$i',$i,"; done;
> >> echo "'0',0);"; ) | psql
> >> I got server crash with the following backtrace
>
> > Hah, of course. I suppose we'd need something like this ... haven't
> > looked for other problem spots.
>
> 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.

At the very least we cannot exceed MaxAttrNumber, so that we can
reference any columns with an AttrNumber (int16). But if there are more
than MaxTupleAttributeNumber columns, we would end up error out when
constructing the tuple in heap_form_tuple().

Thanks
Richard

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Richard Guo 2022-07-29 16:24:06 Re: BUG #17561: Server crashes on executing row() with very long argument list
Previous Message Tom Lane 2022-07-29 14:40:55 Re: BUG #17561: Server crashes on executing row() with very long argument list