Phil Sorber <phil (AT) omniti (DOT) com> writes:
How about a test case? I have no faith in the proposed patch without
some evidence of what it's supposed to fix.

regards, tom lane

--
Sent via pgsql-bugs mailing list (pgsql-bugs (AT) postgresql (DOT) org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Phil Sorber <phil (AT) omniti (DOT) com> writes:
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 (AT) postgresql (DOT) org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Phil Sorber <phil (AT) omniti (DOT) com> writes:
[ pokes at that... ] Hmm. I think what this proves is that that
optimization in EvalPlanQualStart is just too cute for its own good,
and that the only safe fix is to take it out. That code path is
(obviously) none too well tested, so we should not have it setting
up execution tree structures that are not like those used normally.
It's just begging for trouble.

regards, tom lane

--
Sent via pgsql-bugs mailing list (pgsql-bugs (AT) postgresql (DOT) org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

On Wed, Jan 25, 2012 at 5:13 PM, Tom Lane <tgl (AT) sss (DOT) pgh.pa.us> wrote:
I played around with removing the optimization, but there are other
pieces further down the line that are upset but having a ModifyTable
node in the execution tree. Specifically this:

http://git.postgresql.org/gitweb/?p=...232 9d4f#l900

Not sure at all how to proceed from there so I am deferring. Perhaps
the original authors can be asked to weigh in? We changed our writable
CTE queries to update/insert loops so this is no longer a blocker for
us.

--
Sent via pgsql-bugs mailing list (pgsql-bugs (AT) postgresql (DOT) org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Phil Sorber <phil (AT) omniti (DOT) com> writes:
Hm, yeah, obviously this scenario has never been tested :-(. I have
applied a patch for it, and also done some work so that it will get
tested by the buildfarm in future. Thanks for the report!

FWIW, that technique didn't really work anyway, as even with the patch
I observe that you get a "duplicate unique key" failure if two such
commands try to insert a new row concurrently. This is because neither
UPDATE subquery will see an as-yet-uncommitted inserted row.

regards, tom lane

--
Sent via pgsql-bugs mailing list (pgsql-bugs (AT) postgresql (DOT) org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs