| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> |
| Cc: | Kyle Samson <kysamson(at)tripadvisor(dot)com>, "pgsql-hackers\(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Matthew Kelly <mkelly(at)tripadvisor(dot)com> |
| Subject: | Re: Consistent segfault in complex query |
| Date: | 2018-09-13 22:18:42 |
| Message-ID: | 5943.1536877122@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
I wrote:
> Your other idea of forcing initPlan parameters to be evaluated before we
> enter the EPQ execution environment is probably more workable.
Concretely, the attached seems to be enough to fix it (though I only
tried the simplest case you posted).
I don't find anything to love about ExecEvalParamExecParams: it's badly
named, badly located, full of undocumented assumptions, and probably
causes a memory leak. Plus it doesn't exist as far back as we need it
for this. But fixing those problems is a separable task. In the
meantime, this is an expedient way to test whether this approach can work.
regards, tom lane
| Attachment | Content-Type | Size |
|---|---|---|
| quick-fix-for-EPQ-initplan-problem.patch | text/x-diff | 1.2 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2018-09-13 22:29:36 | Re: Consistent segfault in complex query |
| Previous Message | Andrew Gierth | 2018-09-13 22:12:22 | Re: Consistent segfault in complex query |