Re: Segfault in backend CTE code
От | Phil Sorber |
---|---|
Тема | Re: Segfault in backend CTE code |
Дата | |
Msg-id | CADAkt-ix+ts5V1aHx2gHtRogUnKciJ6B5c5s-RTobp70WWjrXQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Segfault in backend CTE code (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Segfault in backend CTE code
|
Список | pgsql-bugs |
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
В списке pgsql-bugs по дате отправления: