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
(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 Kaltenbrunner||Date: 2012-01-24 21:34:32|
|Subject: Re: pgcrypto decrypt_iv() issue|
|Previous:||From: Phil Sorber||Date: 2012-01-24 20:22:45|
|Subject: Re: Segfault in backend CTE code|