On Wed, Jan 3, 2018 at 4:31 PM, Alvaro Herrera <alvhe...@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
