From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, pgsql-committers(at)postgresql(dot)org |
Subject: | Re: pgsql: Fix deadlock hazard in CREATE INDEX CONCURRENTLY |
Date: | 2018-01-03 21:31:56 |
Message-ID: | 20180103213156.s5havue6rmdskvra@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers |
Tom Lane wrote:
> No, I think that's probably a bad idea, because it would mean that in
> cases where you do care about the finishing order (which is all of
> them up to now), the test output would fail to prove that you got the
> expected behavior.
Hmm .. I was thinking that we would check all the steps that are
unlocked when running a single one, so the only test that would be
affected would be deadlock-hard, which has this:
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.
> At this point I'm on board with using an alternate expected file.
> We could revert the test back to your original version and make
> the pre-9.6 branches look the same, which would be good.
I reverted the test change, so the tests are now the same everywhere. I
hadn't touched 9.4 and 9.5 previously. The failures in 9.6-10-master
had been accumulating fast, and we didn't have a single failure in 9.4
and 9.5, so I'm hoping that this means the older branches just cannot
fail in this way. But we shall see.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2018-01-03 22:12:50 | pgsql: Fix typo |
Previous Message | Thomas Munro | 2018-01-03 21:24:43 | Re: pgsql: Allow ldaps when using ldap authentication |