On Wed, Jan 3, 2018 at 4:31 PM, Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
> step s8a1: LOCK TABLE a1; <waiting ...>
> step s8a1: <... completed>
> step s7a8: <... completed>
> error in steps s8a1 s7a8: ERROR: deadlock detected
>
> TBH I'm surprised that this is never reported in the other order but
> that this doesn't hold for the new test, but there you have it.
That test was quite unstable at first (although not on the machine
where I developed it, sigh). But now session s7 sets deadlock_timeout
= '100s' and session s8 sets deadlock_timeout = '10s', which is
apparently sufficient insulation against timing variations. The
original commit used 10ms and 10s, and that wasn't good enough.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company