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