Phil Sorber <p...@omniti.com> writes:
> On Tue, Jan 24, 2012 at 12:43 AM, Tom Lane <t...@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
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
