Re: Segfault in backend CTE code

Phil Sorber <phil@omniti.com> writes:
> On Tue, Jan 24, 2012 at 12:43 AM, Tom Lane <tgl@sss.pgh.pa.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