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