On Wed, Jan 25, 2012 at 5:13 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Phil Sorber <phil@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... ] =A0Hmm. =A0I 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. =A0That 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=3Dpostgresql.git;a=3Dblob;f=3Dsrc/backe=
nd/executor/nodeModifyTable.c;h=3Dcf32dc569037f710ce6c43c4c93ee3a10cabe085;=
hb=3D389af951552ff2209eae3e62fa147fef12329d4f#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.
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0regards, tom lane
