]> granicus.if.org Git - postgresql/commit
Fix busted logic for parallel lock grouping in TopoSort().
authorTom Lane <tgl@sss.pgh.pa.us>
Mon, 29 Jul 2019 22:49:04 +0000 (18:49 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Mon, 29 Jul 2019 22:49:04 +0000 (18:49 -0400)
commit3420851a2c2d2ac49b8ba53ccec5d02aa1e6a272
tree774e48b37736330eaa9bdaf93c9028928ddc8b81
parent1e2fddfa33d3c7cc93ca3ee0f32852699bd3e012
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
src/backend/storage/lmgr/deadlock.c