I wrote:
>>> (A couple of the other isolation tests do fail reliably under this
>>> scenario; is it worth hardening them?)
>> Yes, I think it's worth making them pass somehow -- see commits
>> f18795e7b74c, a0eae1a2eeb6.
> Will look into that too. I'm not sure that adding extra expected
> outputs is sane, though --- might be best to just force the intended
> isolation level within those tests.
Hmm, so one of the ones that fails is lock-update-delete, which I see
*already has* an alternate output file for serializable mode ... but
it doesn't match what I get:
*** /home/postgres/pgsql/src/test/isolation/expected/lock-update-delete_1.out Mon Feb 12 14:53:46 2018
--- /home/postgres/pgsql/src/test/isolation/output_iso/results/lock-update-delete.out Wed Apr 18 11:30:23 2018
***************
*** 150,156 ****
t
step s1l: <... completed>
! error in steps s2_unlock s1l: ERROR: could not serialize access due to concurrent update
starting permutation: s2b s1l s2u s2_blocker1 s2r s2_unlock
pg_advisory_lock
--- 150,158 ----
t
step s1l: <... completed>
! key value
!
! 1 1
starting permutation: s2b s1l s2u s2_blocker1 s2r s2_unlock
pg_advisory_lock
It looks like maybe this one wasn't updated in 533e9c6b0 --- would
you check/confirm that?
regards, tom lane