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 <alvhe...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
