On Wed, Jan 25, 2012 at 5:13 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Phil Sorber <p...@omniti.com> writes:
>> That helped a lot. I now have a simple test case that I can reliably
>> re-produce the segfault and now also a patch that fixes it.
>
> [ pokes at that... ]  Hmm.  I think what this proves is that that
> optimization in EvalPlanQualStart is just too cute for its own good,
> and that the only safe fix is to take it out.  That code path is
> (obviously) none too well tested, so we should not have it setting
> up execution tree structures that are not like those used normally.
> It's just begging for trouble.

I played around with removing the optimization, but there are other
pieces further down the line that are upset but having a ModifyTable
node in the execution tree. Specifically this:

http://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/backend/executor/nodeModifyTable.c;h=cf32dc569037f710ce6c43c4c93ee3a10cabe085;hb=389af951552ff2209eae3e62fa147fef12329d4f#l900

Not sure at all how to proceed from there so I am deferring. Perhaps
the original authors can be asked to weigh in? We changed our writable
CTE queries to update/insert loops so this is no longer a blocker for
us.

>
>                        regards, tom lane

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Reply via email to