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