Обсуждение: BUG #15428: "Inception" with recursive prepared statement causesinfinite loop
BUG #15428: "Inception" with recursive prepared statement causesinfinite loop
От
PG Bug reporting form
Дата:
The following bug has been logged on the website: Bug reference: 15428 Logged by: Malthe Borch Email address: mborch@gmail.com PostgreSQL version: 11beta4 Operating system: MacOS Description: Using the extended query message flow, I prepare, bind and execute a query as a named statement. If I repeat this again with the query "execute <name>" – the backend crashes with a segmentation fault due to an infinite recursion (see excerpt below). While it doesn't really make sense to prepare a statement that executes a statement, there still seems to be a real issue here. It doesn't seem to make a difference using the unnamed portal or a unique name per statement. ---- * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=2, address=0x7ffeef3fffa8) * frame #0: 0x000000010073b49a postgres`dopr(target=<unavailable>, format=<unavailable>, args=<unavailable>) at snprintf.c:377 frame #1: 0x000000010073c84f postgres`pg_vsprintf(str="0\x04@??", fmt="<unnamed portal %u>", args=0x00007ffeef4003c0) at snprintf.c:223 frame #2: 0x000000010073ca0c postgres`pg_sprintf(str="0\x04@??", fmt="<unnamed portal %u>") at snprintf.c:236 frame #3: 0x000000010070d842 postgres`CreateNewPortal at portalmem.c:244 frame #4: 0x000000010025a3f2 postgres`ExecuteQuery(stmt=0x000000010200aa48, intoClause=0x0000000000000000, queryString="execute test($1)", params=0x0000000000000000, dest=0x000000010093da08, completionTag="") at prepare.c:237 frame #5: 0x0000000100512924 postgres`standard_ProcessUtility(pstmt=0x000000010200a9b0, queryString="execute test($1)", context=PROCESS_UTILITY_QUERY, params=0x0000000000000000, queryEnv=0x0000000000000000, dest=0x000000010093da08, completionTag="") at utility.c:564 frame #6: 0x00000001005123a5 postgres`ProcessUtility(pstmt=0x000000010200a9b0, queryString="execute test($1)", context=PROCESS_UTILITY_QUERY, params=0x0000000000000000, queryEnv=0x0000000000000000, dest=0x000000010093da08, completionTag="") at utility.c:360 frame #7: 0x0000000100511d87 postgres`PortalRunUtility(portal=0x000000010e912c88, pstmt=0x000000010200a9b0, isTopLevel=<unavailable>, setHoldSnapshot=<unavailable>, dest=<unavailable>, completionTag="") at pquery.c:1178 frame #8: 0x00000001005114e4 postgres`PortalRunMulti(portal=0x000000010e912c88, isTopLevel=false, setHoldSnapshot=false, dest=0x000000010093da08, altdest=0x000000010093da08, completionTag="") at pquery.c:0 frame #9: 0x0000000100510d4e postgres`PortalRun(portal=0x000000010e912c88, count=9223372036854775807, isTopLevel=false, run_once=<unavailable>, dest=0x000000010093da08, altdest=0x000000010093da08, completionTag="") at pquery.c:799 frame #10: 0x000000010025a632 postgres`ExecuteQuery(stmt=0x000000010200aa48, intoClause=0x0000000000000000, queryString="execute test($1)", params=0x0000000000000000, dest=0x000000010093da08, completionTag="") at prepare.c:304
> Using the extended query message flow, I prepare, bind and execute a query > as a named statement. > If I repeat this again with the query "execute <name>" – the backend crashes > with a segmentation fault due to an infinite recursion (see excerpt > below). Hm, yeah. I'm inclined to think that the right fix is a check_stack_depth() call in standard_ProcessUtility. That transforms the case into $ ./test PQexecPrepared failed: ERROR: stack depth limit exceeded HINT: Increase the configuration parameter "max_stack_depth" (currently 2048kB), after ensuring the platform's stack depthlimit is adequate. which seems like an adequate response, and would cover some related scenarios as well. regards, tom lane