| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andres Freund <andres(at)anarazel(dot)de>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, pgsql-committers <pgsql-committers(at)postgresql(dot)org> |
| Subject: | Re: pgsql: Fix deadlock hazard in CREATE INDEX CONCURRENTLY |
| Date: | 2018-01-04 03:40:32 |
| Message-ID: | CA+TgmoYQ4fkdnjvRMhF_qdbekPOT=iJ1FPtKnYhXnK5L+V6pVQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-committers |
On Wed, Jan 3, 2018 at 4:31 PM, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2018-01-04 06:07:01 | pgsql: Tweak parallel hash join test case in hopes of improving stabili |
| Previous Message | Tom Lane | 2018-01-04 02:09:24 | Re: pgsql: Add parallel-aware hash joins. |