aboutsummaryrefslogtreecommitdiff
path: root/src/backend/commands/analyze.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2019-07-29 18:49:04 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2019-07-29 18:49:04 -0400
commit0dcb1c6c4874d2d464d426ded208b58b01e52174 (patch)
tree6f0e55c0a4764ce3a9e41a5dfb265f331a231e74 /src/backend/commands/analyze.c
parent0ef70bbaddb6b725c1d0d72bcf607ef9fdba0c1c (diff)
downloadpostgresql-0dcb1c6c4874d2d464d426ded208b58b01e52174.tar.gz
postgresql-0dcb1c6c4874d2d464d426ded208b58b01e52174.zip
Fix busted logic for parallel lock grouping in TopoSort().
A "break" statement erroneously left behind by commit a1c1af2a1 caused TopoSort to do the wrong thing if a lock's wait list contained multiple members of the same locking group. Because parallel workers don't normally need any locks not already taken by their leader, this is very hard --- maybe impossible --- to hit in production. Still, if it did happen, the queries involved in an otherwise-resolvable deadlock would block until canceled. In addition to removing the bogus "break", add an Assert showing that the conflicting uses of the beforeConstraints[] array (for both counts and flags) don't overlap, and add some commentary explaining why not; because it's not obvious without explanation, IMHO. Original report and patch from Rui Hai Jiang; additional assert and commentary by me. Back-patch to 9.6 where the bug came in. Discussion: https://postgr.es/m/CAEri+mLd3bpHLyW+a9pSe1y=aEkeuJpwBSwvo-+m4n7-ceRmXw@mail.gmail.com
Diffstat (limited to 'src/backend/commands/analyze.c')
0 files changed, 0 insertions, 0 deletions