Re: Segfault in backend CTE code

Phil Sorber <phil(at)omniti(dot)com> writes:
> On Tue, Jan 24, 2012 at 12:43 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> How about a test case?

> We are having trouble coming up with a test case that can reliably
> reproduce this.

The stack traces run through the EvalPlanQual machinery, which is only
going to be entered when attempting to update/delete a row that's been
updated by a concurrent transaction. So what I'd suggest for creating a
test case is

(1) in a psql session, do
BEGIN;
UPDATE some-target-row;

(2) in another psql session, call this function with arguments
that will make it try to update that same row; it should
block.

(3) in the first session, COMMIT to unblock.

FWIW, having re-examined your patch with some caffeine in me, I don't
think it's right at all. You can't just blow off setting the scan type
for a CTEScan node. What it looks like to me is that the EvalPlanQual
code is not initializing the new execution tree correctly; but that
idea would be a lot easier to check into with a test case.

regards, tom lane