Re: pgsql: Fix deadlock hazard in CREATE INDEX CONCURRENTLY - Mailing list pgsql-committers

From Tom Lane
Subject Re: pgsql: Fix deadlock hazard in CREATE INDEX CONCURRENTLY
Date
Msg-id 28821.1519437540@sss.pgh.pa.us
Whole thread Raw
In response to Re: pgsql: Fix deadlock hazard in CREATE INDEX CONCURRENTLY  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-committers
So we're still not out of the woods with that CREATE INDEX CONCURRENTLY
deadlock test.  Buildfarm member okapi has failed most (not all) of its
runs since that patch went in, but only in the 9.4 branch.  The failures
look like

*** /home/data/buildfarm/root.x86_64/REL9_4_STABLE/pgsql.build/src/test/isolation/expected/multiple-cic.out    Thu Feb
2202:35:05 2018 
--- /home/data/buildfarm/root.x86_64/REL9_4_STABLE/pgsql.build/src/test/isolation/results/multiple-cic.out    Thu Feb
2202:44:48 2018 
***************
*** 14,19 ****
--- 14,20 ----
          WHERE unlck();

  step s1i: <... completed>
+ error in steps s2i s1i: ERROR:  deadlock detected
  s1

as though the bug hadn't been fixed at all.

I have no idea what to make of this.  I'd easily believe a 9.4-only bug,
but why is okapi the only critter showing it?  It doesn't seem to be a
particularly unusual platform or build configuration.

I thought maybe it's a timing issue, but fooling about with altering
the timing by injecting sleeps hasn't allowed me to reproduce it here.

I do notice that okapi is running a not-very-new icc version with -O3,
opening the possibility that there's a compiler bug or at least an
undesirable optimization going on.  It might be interesting to find out
if the failure is still reproducible at lower -O levels.

            regards, tom lane


pgsql-committers by date:

Previous
From: Tom Lane
Date:
Subject: pgsql: First-draft release notes for 10.3.
Next
From: Peter Eisentraut
Date:
Subject: pgsql: Fix filtering of unsupported relations in logical replication