Re: Consistent segfault in complex query

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-14 19:55:40
Message-ID: 5688.1536954940@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> writes:
> If it helps, here is a patch that adds isolation tests to
> eval-plan-qual.spec for two test cases (one with CTE, one without).
> I've verified that these reproduce the crash, and that they run
> successfully with your patch. I can't currently see any more specific
> code paths to probe in these tests.

Thanks! I incorporated these into the attached proposed patches.

The main difference from what I had yesterday is that I rewrote
ExecEvalParamExecParams to my satisfaction. The crucial thing I didn't
like about it was that it hard-wired use of the GetPerTupleExprContext
econtext for initplan evaluation. That seemed like it risked memory
leaks in case of repeated initplan evaluation for a single top-level
output tuple. I've since convinced myself that it's basically impossible
to leak memory in ExecSetParamPlan right now (cf comments below), but
that doesn't seem like an assumption to bake into an API when it isn't
even buying us anything to do so.

The attached is split into two parts because 0001 will need to go all
the way back, whereas 0002 only applies to HEAD and v11. I don't
plan to make them separate commits though.

A quick test says that back-patching 0001 might be slightly painful;
a lot of the hunks don't apply. I've not looked at why not.

regards, tom lane

Attachment Content-Type Size
0001-epq-initplan-fix-1.patch text/x-diff 8.9 KB
0002-remove-ExecEvalParamExecParams-1.patch text/x-diff 4.3 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2018-09-14 19:57:06 Re: pg_dump test instability
Previous Message Jordan Deitch 2018-09-14 19:17:43 Re: Delta Materialized View Refreshes?