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

Re: Segfault in backend CTE code

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Phil Sorber <phil(at)omniti(dot)com>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: Segfault in backend CTE code
Date: 2012-01-24 21:03:04
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-bugs
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
		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

	(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

In response to


pgsql-bugs by date

Next:From: Stefan KaltenbrunnerDate: 2012-01-24 21:34:32
Subject: Re: pgcrypto decrypt_iv() issue
Previous:From: Phil SorberDate: 2012-01-24 20:22:45
Subject: Re: Segfault in backend CTE code

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