Skip site navigation (1) Skip section navigation (2)

Re: Segfault in backend CTE code

From: Phil Sorber <phil(at)omniti(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: Segfault in backend CTE code
Date: 2012-01-25 21:01:35
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-bugs
I screwed up cut and paste when putting the test case together. The
reference to table user_data should be t1.

On Wed, Jan 25, 2012 at 12:47 PM, Phil Sorber <phil(at)omniti(dot)com> wrote:
> On Tue, Jan 24, 2012 at 4:03 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> 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.
> 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. I had to
> modify the patch slightly because while it fixed the first problem, it
> just cascaded to another NULL deref from the same root cause. Both are
> attached.
>> 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.
> If I understand what you are saying, then I agree that is the root of
> the problem. The comment label's it as an optimization, but then later
> fails to account for all the changes needed. My patch accounts for at
> least one extra change that is needed. We could also remove the
> "optimization" but I assumed it was there for a reason, especially
> given the fact that someone took the time to make a comment about it.
> The change was made in this commit by you:
>>                        regards, tom lane

Attachment: CTE_segfault_test_case_v2.txt
Description: text/plain (1.1 KB)

In response to

pgsql-bugs by date

Next:From: Giuseppe SucameliDate: 2012-01-25 21:19:46
Subject: Re: Different error messages executing CREATE TABLE or ALTER TABLE to create a column "xmin"
Previous:From: Phil SorberDate: 2012-01-25 17:47:06
Subject: Re: Segfault in backend CTE code

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group