Re: isolation test deadlocking on buildfarm member coypu

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-oWPeuURCDnjR@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