On Tue, Jul 26, 2011 at 05:04:28PM -0400, Alvaro Herrera wrote: > *** > /home/pgbuildfarm/workdir/HEAD/pgsql.20950/src/test/isolation/expected/fk-deadlock2.out > Sun Jul 24 08:46:44 2011 > --- > /home/pgbuildfarm/workdir/HEAD/pgsql.20950/src/test/isolation/results/fk-deadlock2.out > Sun Jul 24 15:11:42 2011 > *************** > *** 22,29 **** > step s2u1: UPDATE B SET Col2 = 1 WHERE BID = 2; > step s1u2: UPDATE B SET Col2 = 1 WHERE BID = 2; <waiting ...> > step s2u2: UPDATE B SET Col2 = 1 WHERE BID = 2; > - step s1u2: <... completed> > ERROR: deadlock detected > step s1c: COMMIT; > step s2c: COMMIT; > > --- 22,29 ---- > step s2u1: UPDATE B SET Col2 = 1 WHERE BID = 2; > step s1u2: UPDATE B SET Col2 = 1 WHERE BID = 2; <waiting ...> > step s2u2: UPDATE B SET Col2 = 1 WHERE BID = 2; > ERROR: deadlock detected > + step s1u2: <... completed> > step s1c: COMMIT; > step s2c: COMMIT; > > > > I think the only explanation necessary for this is that one process > reports its status before the other one. I think it would be enough to > add another variant of the expected file to fix this problem, but I > don't quite want to do that because we already have three of them, and I > think we would need to add one per existing expected, so we'd end up > with 6 expected files which would be a pain to work with.
To really cover the problem in this way, we would need 16*3 variations covering every permutation of the deadlocks detected when s1 runs the first command. I see these other options: 1. Keep increasing the s1 deadlock_timeout until we stop getting these. This is simple, but it proportionally slows the test suite for everyone. No value will ever be guaranteed sufficient. 2. Post-process the output to ascribe the deadlock detections in a standard way before comparing with expected output. This would also let us drop deadlock_timeout arbitrarily low, giving a rapid test run. 3. Implement actual deadlock priorities, per discussion at http://archives.postgresql.org/message-id/aanlktimaqfzkv4sc1dscrufft_be78y-owpeuurcd...@mail.gmail.com This is much more work, but it would let us drop deadlock_timeout arbitrarily low and still get consistent results from the start. -- Noah Misch 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
