Re: BUG #17561: Server crashes on executing row() with very long argument list
| От | Richard Guo |
|---|---|
| Тема | Re: BUG #17561: Server crashes on executing row() with very long argument list |
| Дата | |
| Msg-id | CAMbWs4_wzOXFuK1xtHPHLiN5LvvhxzbTBeRBZ7jisL7aznALhg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: BUG #17561: Server crashes on executing row() with very long argument list (Tom Lane <tgl@sss.pgh.pa.us>) |
| Список | pgsql-bugs |
On Fri, Jul 29, 2022 at 9:56 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Alvaro Herrera <alvherre@alvh.no-ip.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 morethan MaxTupleAttributeNumber columns, we would end up error out when
constructing the tuple in heap_form_tuple().
Thanks
Richard
В списке pgsql-bugs по дате отправления: