Horton

Thread

Commits

  1. Check for stack overrun in standard_ProcessUtility().

  1. BUG #15428: "Inception" with recursive prepared statement causes infinite loop

    The Post Office <noreply@postgresql.org> — 2018-10-12T09:00:12Z

    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

  2. Re: BUG #15428: "Inception" with recursive prepared statement causes infinite loop

    Tom Lane <tgl@sss.pgh.pa.us> — 2018-10-15T16:21:41Z

    > 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 depth limit is adequate.

which seems like an adequate response, and would cover some
related scenarios as well.

			regards, tom lane