Greg Stark <gsst...@mit.edu> writes:
> On Fri, Dec 11, 2009 at 6:08 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> I'll commit a fix for that shortly, but this reminds me once again that
>> the EvalPlanQual logic is desperately under-tested in our normal
>> regression testing. We really need some kind of testing infrastructure
>> that would let us exercise concurrent-update cases a bit more than "not
>> at all".
> If i went back and cleaned up the parallel psql patch we would be able
> to write tests which tested basic concurrent functionality such as
> transactions blocking when they're supposed to. But that wouldn't
> catch something like this I don't think, not unless it got triggered
> pretty reliably by a simple evalplanqual recheck.
It would have been caught if anyone had tried an EvalPlanQual'd update on
a table with one of the unchanged columns being a non-null pass-by-ref
value. Now it's certainly possible that a set of regression tests would
by chance fail to exercise that case --- but IMO the real problem right
now is we aren't even trying to exercise EvalPlanQual; we're actively
avoiding it because the current test infrastructure can't ensure
deterministic results if any such situation arises.
But my recollection of the parallel psql patch discussion is that it was
rejected because nobody felt comfortable with the API design. Do we
have any better ideas in that department yet?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
