Re[2]: BUG #17561: Server crashes on executing row() with very long argument list
| От | Егор Чиндяскин |
|---|---|
| Тема | Re[2]: BUG #17561: Server crashes on executing row() with very long argument list |
| Дата | |
| Msg-id | 1659338229.499665470@f479.i.mail.ru обсуждение исходный текст |
| Ответ на | Re: BUG #17561: Server crashes on executing row() with very long argument list (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: Re[2]: BUG #17561: Server crashes on executing row() with very long argument list
(Richard Guo <guofenglinux@gmail.com>)
|
| Список | pgsql-bugs |
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
В списке pgsql-bugs по дате отправления:
Предыдущее
От: Ajin CherianДата:
Сообщение: Re: Excessive number of replication slots for 12->14 logical replication
Следующее
От: Michael PaquierДата:
Сообщение: Re: BUG #17563: exception " Segmentation fault" occured when i executed 'reindex index concurrently' in pg12.0