On 2013-08-05 14:37:34 -0400, Robert Haas wrote:
> On Fri, Aug 2, 2013 at 5:25 PM, Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
> >> The attached test case runs under isolationtester to exersise the
> >> problem. I've tested it against 9.2, 9.3, and HEAD, but Andres looked
> >> over the code and says the underlying bug goes back to the commit of
> >> MVCC, it's just become easier to trigger. To reliably test this with
> >> isolationtester I had to horribly abuse pg_advisory_lock(...) so that I
> >> could force the first SELECT ... FOR UPDATE to acquire its snapshot
> >> before the UPDATE runs.
> >
> > I didn't apply the test case. I think if we want to test tqual.c
> > behavior we will need to introduce a large battery of tests. I would
> > like to see more opinions on whether that's something we want.
>
> I haven't read this particular test, but I do think we could get a lot
> of mileage out of applying the isolation tester stuff to more things,
> and am generally in favor of that.
The "problem" with the specific test is that it uses row level locks to
get to the situation where EvalPlanQualFetch has to chase down a ctid
chain by making a READ COMITTED transaction acquire a snapshot and only
after that wait.
Not sure if that's not too involved.
> It has the advantages of (1)
> allowing tests that require more than one session and (2) being run
> regularly the buildfarm; but it's not something developers typically
> run before every commit, so the run time of the test suite shouldn't
> be a big issue for anyone.
Agreed.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services
