| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | mborch(at)gmail(dot)com |
| Cc: | pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Subject: | Re: BUG #15428: "Inception" with recursive prepared statement causes infinite loop |
| Date: | 2018-10-15 16:21:41 |
| Message-ID: | 1316.1539620501@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
> 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2018-10-15 18:48:24 | Re: Index-only scan returns incorrect results when using a composite GIST index with a gist_trgm_ops column. |
| Previous Message | Tom Lane | 2018-10-15 15:02:27 | Re: BUG #15432: ddl logging includes password in plaintext |