On 2013-08-06 04:48:09 +0200, Andres Freund wrote:
> 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.
Errr, s/row level locks/advisory locks/
Thanks Craig,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services
