pg.ddx.io pgsql-bugs@postgresql.org mailing list archive
help / color / mirror / Atom feed Re[2]: BUG #17561: Server crashes on executing row() with very long argument list
5+ messages / 3 participants
[nested] [flat]
* Re[2]: BUG #17561: Server crashes on executing row() with very long argument list
@ 2022-08-01 07:17 Егор Чиндяскин <kyzevan23@mail.ru>
2022-08-01 10:03 ` Re: Re[2]: BUG #17561: Server crashes on executing row() with very long argument list Richard Guo <guofenglinux@gmail.com>
0 siblings, 1 reply; 5+ messages in thread
From: Егор Чиндяскин @ 2022-08-01 07:17 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>; PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>; Richard Guo <guofenglinux@gmail.com>
Thank you, Tom! The fix works for that case, but there is another one.
I got server crashed while executing the following script:
(echo "SELECT * FROM json_to_record('{\"0\":0 ";for((i=1;i<100001;i++));do echo ",\"$i\":$i";done; echo "}') as x("; echo "\"0\" int";for((i=1;i<100001;i++));do echo ",\"$i\" int";done;echo ")") | psql
Core was generated by `postgres: postgres postgres [local] SELECT '.
Program terminated with signal SIGABRT, Aborted.
#0 __pthread_kill_implementation (no_tid=0, signo=6, threadid=139778293300096) at ./nptl/pthread_kill.c:44
44 ./nptl/pthread_kill.c: Нет такого файла или каталога.
(gdb) bt
#0 __pthread_kill_implementation (no_tid=0, signo=6, threadid=139778293300096) at ./nptl/pthread_kill.c:44
#1 __pthread_kill_internal (signo=6, threadid=139778293300096) at ./nptl/pthread_kill.c:78
#2 __GI___pthread_kill (threadid=139778293300096, signo=signo@entry=6) at ./nptl/pthread_kill.c:89
#3 0x00007f20ab893476 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
#4 0x00007f20ab8797f3 in __GI_abort () at ./stdlib/abort.c:79
#5 0x0000561dac149915 in ExceptionalCondition (conditionName=conditionName@entry=0x561dac1ad8e2 "attributeNumber >= 1", errorType=errorType@entry=0x561dac1ab917 "BadArgument", fileName=fileName@entry=0x561dac1ad7fc "tupdesc.c", lineNumber=lineNumber@entry=598)
at assert.c:69
#6 0x0000561dabbfa25f in TupleDescInitEntry (desc=0x7f209d380050, attributeNumber=attributeNumber@entry=-32768, attributeName=attributeName@entry=0x7f20a0579bd8 "32767", oidtypeid=23, typmod=-1, attdim=attdim@entry=0) at tupdesc.c:598
#7 0x0000561dabd59688 in addRangeTableEntryForFunction (pstate=pstate@entry=0x7f209e02a450, funcnames=funcnames@entry=0x7f209e02aec0, funcexprs=funcexprs@entry=0x7f209e02ae68, coldeflists=coldeflists@entry=0x7f209e02af70, rangefunc=rangefunc@entry=0x561dacc7dc70,
lateral=<optimized out>, inFromCl=true) at parse_relation.c:1866
#8 0x0000561dabd3ac10 in transformRangeFunction (pstate=pstate@entry=0x7f209e02a450, r=r@entry=0x561dacc7dc70) at parse_clause.c:669
#9 0x0000561dabd3b488 in transformFromClauseItem (pstate=pstate@entry=0x7f209e02a450, n=0x561dacc7dc70, top_nsitem=top_nsitem@entry=0x7ffc69d1e738, namespace=namespace@entry=0x7ffc69d1e740) at parse_clause.c:1092
#10 0x0000561dabd3c32e in transformFromClause (pstate=pstate@entry=0x7f209e02a450, frmList=0x7f209e02a378) at parse_clause.c:132
#11 0x0000561dabd196a4 in transformSelectStmt (pstate=0x7f209e02a450, stmt=stmt@entry=0x561dacd4f948) at analyze.c:1313
#12 0x0000561dabd1a19e in transformStmt (pstate=pstate@entry=0x7f209e02a450, parseTree=parseTree@entry=0x561dacd4f948) at analyze.c:365
#13 0x0000561dabd1b455 in transformOptionalSelectInto (pstate=pstate@entry=0x7f209e02a450, parseTree=0x561dacd4f948) at analyze.c:305
#14 0x0000561dabd1b48a in transformTopLevelStmt (pstate=pstate@entry=0x7f209e02a450, parseTree=parseTree@entry=0x7f20a0df7fe0) at analyze.c:255
#15 0x0000561dabd1b4f2 in parse_analyze_fixedparams (parseTree=parseTree@entry=0x7f20a0df7fe0,
sourceText=sourceText@entry=0x7f20a15ca050 "SELECT * FROM json_to_record('{\"0\":0 \n,\"1\":1\n,\"2\":2\n,\"3\":3\n,\"4\":4\n,\"5\":5\n,\"6\":6\n,\"7\":7\n,\"8\":8\n,\"9\":9\n,\"10\":10\n,\"11\":11\n,\"12\":12\n,\"13\":13\n,\"14\":14\n,\"15\":15\n,\"16\":16\n,\"17\":17\n,\"18\":18\n,\"19\":19\n,\"20\":20\n"..., paramTypes=paramTypes@entry=0x0, numParams=numParams@entry=0, queryEnv=queryEnv@entry=0x0) at analyze.c:123
#16 0x0000561dabffea49 in pg_analyze_and_rewrite_fixedparams (parsetree=parsetree@entry=0x7f20a0df7fe0,
query_string=query_string@entry=0x7f20a15ca050 "SELECT * FROM json_to_record('{\"0\":0 \n,\"1\":1\n,\"2\":2\n,\"3\":3\n,\"4\":4\n,\"5\":5\n,\"6\":6\n,\"7\":7\n,\"8\":8\n,\"9\":9\n,\"10\":10\n,\"11\":11\n,\"12\":12\n,\"13\":13\n,\"14\":14\n,\"15\":15\n,\"16\":16\n,\"17\":17\n,\"18\":18\n,\"19\":19\n,\"20\":20\n"..., paramTypes=paramTypes@entry=0x0, numParams=numParams@entry=0, queryEnv=queryEnv@entry=0x0) at postgres.c:650
#17 0x0000561dabfff1a9 in exec_simple_query (
query_string=query_string@entry=0x7f20a15ca050 "SELECT * FROM json_to_record('{\"0\":0 \n,\"1\":1\n,\"2\":2\n,\"3\":3\n,\"4\":4\n,\"5\":5\n,\"6\":6\n,\"7\":7\n,\"8\":8\n,\"9\":9\n,\"10\":10\n,\"11\":11\n,\"12\":12\n,\"13\":13\n,\"14\":14\n,\"15\":15\n,\"16\":16\n,\"17\":17\n,\"18\":18\n,\"19\":19\n,\"20\":20\n"...) at postgres.c:1159
#18 0x0000561dac001138 in PostgresMain (dbname=<optimized out>, username=<optimized out>) at postgres.c:4505
#19 0x0000561dabf55610 in BackendRun (port=port@entry=0x561daccab0e0) at postmaster.c:4490
#20 0x0000561dabf5868f in BackendStartup (port=port@entry=0x561daccab0e0) at postmaster.c:4218
#21 0x0000561dabf588c8 in ServerLoop () at postmaster.c:1808
#22 0x0000561dabf59e8e in PostmasterMain (argc=argc@entry=3, argv=argv@entry=0x561dacc774b0) at postmaster.c:1480
#23 0x0000561dabe7acc1 in main (argc=3, argv=0x561dacc774b0) at main.c:197
Best wishes, Egor Chindyaskin
>Пятница, 29 июля 2022, 23:57 +07:00 от Tom Lane <tgl@sss.pgh.pa.us>:
>
>Richard Guo < guofenglinux@gmail.com > writes:
>> 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.
>As far as I can think, sub-SELECTs and ROW constructs are the only
>SQL that can produce composites of non-pre-determined types.
>For constructs producing named composite types, the limit on the
>number of columns in a table should take care of it.
>
>What I'm more troubled by is whether there are any ways to produce
>a wide tuple that don't come through either the parser or a table
>definition. Not sure what that could look like, other than C code
>randomly constructing a RowExpr or some such.
>
>regards, tom lane
--
Егор Чиндяскин
Отправлено из Почты Mail.ru
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: Re[2]: BUG #17561: Server crashes on executing row() with very long argument list
2022-08-01 07:17 Re[2]: BUG #17561: Server crashes on executing row() with very long argument list Егор Чиндяскин <kyzevan23@mail.ru>
@ 2022-08-01 10:03 ` Richard Guo <guofenglinux@gmail.com>
2022-08-01 10:33 ` Re: Re[2]: BUG #17561: Server crashes on executing row() with very long argument list Richard Guo <guofenglinux@gmail.com>
0 siblings, 1 reply; 5+ messages in thread
From: Richard Guo @ 2022-08-01 10:03 UTC (permalink / raw)
To: Егор Чиндяскин <kyzevan23@mail.ru>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; Alvaro Herrera <alvherre@alvh.no-ip.org>; PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
On Mon, Aug 1, 2022 at 3:17 PM Егор Чиндяскин <kyzevan23@mail.ru> wrote:
> Thank you, Tom! The fix works for that case, but there is another one.
> I got server crashed while executing the following script:
>
> (echo "SELECT * FROM json_to_record('{\"0\":0 ";for((i=1;i<100001;i++));do
> echo ",\"$i\":$i";done; echo "}') as x("; echo "\"0\"
> int";for((i=1;i<100001;i++));do echo ",\"$i\" int";done;echo ")") | psql
>
Thanks for the report! This is another place that we construct a tupdesc
with more than MaxAttrNumber attributes, via RangeFunctions this time.
Regarding the fix, how about we check the length of coldeflist against
MaxTupleAttributeNumber in transformRangeFunction()?
Thanks
Richard
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: Re[2]: BUG #17561: Server crashes on executing row() with very long argument list
2022-08-01 07:17 Re[2]: BUG #17561: Server crashes on executing row() with very long argument list Егор Чиндяскин <kyzevan23@mail.ru>
2022-08-01 10:03 ` Re: Re[2]: BUG #17561: Server crashes on executing row() with very long argument list Richard Guo <guofenglinux@gmail.com>
@ 2022-08-01 10:33 ` Richard Guo <guofenglinux@gmail.com>
2022-08-01 10:51 ` Re: Re[2]: BUG #17561: Server crashes on executing row() with very long argument list Richard Guo <guofenglinux@gmail.com>
0 siblings, 1 reply; 5+ messages in thread
From: Richard Guo @ 2022-08-01 10:33 UTC (permalink / raw)
To: Егор Чиндяскин <kyzevan23@mail.ru>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; Alvaro Herrera <alvherre@alvh.no-ip.org>; PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
On Mon, Aug 1, 2022 at 6:03 PM Richard Guo <guofenglinux@gmail.com> wrote:
>
> On Mon, Aug 1, 2022 at 3:17 PM Егор Чиндяскин <kyzevan23@mail.ru> wrote:
>
>> Thank you, Tom! The fix works for that case, but there is another one.
>> I got server crashed while executing the following script:
>>
>> (echo "SELECT * FROM json_to_record('{\"0\":0
>> ";for((i=1;i<100001;i++));do echo ",\"$i\":$i";done; echo "}') as x("; echo
>> "\"0\" int";for((i=1;i<100001;i++));do echo ",\"$i\" int";done;echo ")") |
>> psql
>>
>
> Thanks for the report! This is another place that we construct a tupdesc
> with more than MaxAttrNumber attributes, via RangeFunctions this time.
>
> Regarding the fix, how about we check the length of coldeflist against
> MaxTupleAttributeNumber in transformRangeFunction()?
>
I mean something like this:
diff --git a/src/backend/parser/parse_clause.c
b/src/backend/parser/parse_clause.c
index 5a18107e79..a74a07667d 100644
inline patch 1: src/backend/parser/parse_clause.c (+0/-0 lines) download inline-1.patch
--- a/src/backend/parser/parse_clause.c
+++ b/src/backend/parser/parse_clause.c
@@ -629,6 +629,15 @@ transformRangeFunction(ParseState *pstate,
* Re: Re[2]: BUG #17561: Server crashes on executing row() with very long argument list
2022-08-01 07:17 Re[2]: BUG #17561: Server crashes on executing row() with very long argument list Егор Чиндяскин <kyzevan23@mail.ru>
2022-08-01 10:03 ` Re: Re[2]: BUG #17561: Server crashes on executing row() with very long argument list Richard Guo <guofenglinux@gmail.com>
2022-08-01 10:33 ` Re: Re[2]: BUG #17561: Server crashes on executing row() with very long argument list Richard Guo <guofenglinux@gmail.com>
@ 2022-08-01 10:51 ` Richard Guo <guofenglinux@gmail.com>
2022-08-01 14:55 ` Re: Re[2]: BUG #17561: Server crashes on executing row() with very long argument list Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 5+ messages in thread
From: Richard Guo @ 2022-08-01 10:51 UTC (permalink / raw)
To: Егор Чиндяскин <kyzevan23@mail.ru>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; Alvaro Herrera <alvherre@alvh.no-ip.org>; PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
On Mon, Aug 1, 2022 at 6:33 PM Richard Guo <guofenglinux@gmail.com> wrote:
>
> On Mon, Aug 1, 2022 at 6:03 PM Richard Guo <guofenglinux@gmail.com> wrote:
>
>>
>> On Mon, Aug 1, 2022 at 3:17 PM Егор Чиндяскин <kyzevan23@mail.ru> wrote:
>>
>>> Thank you, Tom! The fix works for that case, but there is another one.
>>> I got server crashed while executing the following script:
>>>
>>> (echo "SELECT * FROM json_to_record('{\"0\":0
>>> ";for((i=1;i<100001;i++));do echo ",\"$i\":$i";done; echo "}') as x("; echo
>>> "\"0\" int";for((i=1;i<100001;i++));do echo ",\"$i\" int";done;echo ")") |
>>> psql
>>>
>>
>> Thanks for the report! This is another place that we construct a tupdesc
>> with more than MaxAttrNumber attributes, via RangeFunctions this time.
>>
>> Regarding the fix, how about we check the length of coldeflist against
>> MaxTupleAttributeNumber in transformRangeFunction()?
>>
>
> I mean something like this:
>
> diff --git a/src/backend/parser/parse_clause.c
> b/src/backend/parser/parse_clause.c
> index 5a18107e79..a74a07667d 100644
> --- a/src/backend/parser/parse_clause.c
> +++ b/src/backend/parser/parse_clause.c
> @@ -629,6 +629,15 @@ transformRangeFunction(ParseState *pstate,
> RangeFunction *r)
> */
> if (r->coldeflist)
> {
> + /* Disallow more columns than will fit in a tuple */
> + if (list_length(r->coldeflist) > MaxTupleAttributeNumber)
> + ereport(ERROR,
> + (errcode(ERRCODE_TOO_MANY_COLUMNS),
> + errmsg("Function returning RECORD
> can have at most %d entries",
> +
> MaxTupleAttributeNumber),
> + parser_errposition(pstate,
> +
> exprLocation((Node *) r->coldeflist))));
> +
> if (list_length(funcexprs) != 1)
> {
> if (r->is_rowsfrom)
>
>
Just noticed that CheckAttributeNamesTypes will check on column count
against MaxHeapAttributeNumber. Maybe we should use this as the limit?
Thanks
Richard
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: Re[2]: BUG #17561: Server crashes on executing row() with very long argument list
2022-08-01 07:17 Re[2]: BUG #17561: Server crashes on executing row() with very long argument list Егор Чиндяскин <kyzevan23@mail.ru>
2022-08-01 10:03 ` Re: Re[2]: BUG #17561: Server crashes on executing row() with very long argument list Richard Guo <guofenglinux@gmail.com>
2022-08-01 10:33 ` Re: Re[2]: BUG #17561: Server crashes on executing row() with very long argument list Richard Guo <guofenglinux@gmail.com>
2022-08-01 10:51 ` Re: Re[2]: BUG #17561: Server crashes on executing row() with very long argument list Richard Guo <guofenglinux@gmail.com>
@ 2022-08-01 14:55 ` Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 5+ messages in thread
From: Tom Lane @ 2022-08-01 14:55 UTC (permalink / raw)
To: Richard Guo <guofenglinux@gmail.com>; +Cc: Егор Чиндяскин <kyzevan23@mail.ru>; Alvaro Herrera <alvherre@alvh.no-ip.org>; PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Richard Guo <guofenglinux@gmail.com> writes:
> Just noticed that CheckAttributeNamesTypes will check on column count
> against MaxHeapAttributeNumber. Maybe we should use this as the limit?
Yeah, otherwise you'll get a very confusing message about too many
columns in a *table*.
Also, there are two levels we have to check at, per-function and
then the merged tupdesc for the whole RTE.
I should have thought of function RTEs when asserting that there
were no other holes to plug :-(. Will fix, thanks for the report!
regards, tom lane
^ permalink raw reply [nested|flat] 5+ messages in thread
end of thread, other threads:[~2022-08-01 14:55 UTC | newest]
Thread overview: 5+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2022-08-01 07:17 Re[2]: BUG #17561: Server crashes on executing row() with very long argument list Егор Чиндяскин <kyzevan23@mail.ru>
2022-08-01 10:03 ` Richard Guo <guofenglinux@gmail.com>
2022-08-01 10:33 ` Richard Guo <guofenglinux@gmail.com>
2022-08-01 10:51 ` Richard Guo <guofenglinux@gmail.com>
2022-08-01 14:55 ` Tom Lane <tgl@sss.pgh.pa.us>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox