Re: Deadlock in multiple CIC.

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