Обсуждение: pgsql: Introduce group locking to prevent parallel processes from deadl

Introduce group locking to prevent parallel processes from deadlocking.

For locking purposes, we now regard heavyweight locks as mutually
non-conflicting between cooperating parallel processes.  There are some
possible pitfalls to this approach that are not to be taken lightly,
but it works OK for now and can be changed later if we find a better
approach.  Without this, it's very easy for parallel queries to
silently self-deadlock if the user backend holds strong relation locks.

Robert Haas, with help from Amit Kapila.  Thanks to Noah Misch and
Andres Freund for extensive discussion of possible issues with this
approach.

Branch
------
master

Details
-------
http://git.postgresql.org/pg/commitdiff/a1c1af2a1f6099c039f145c1edb52257f315be51

Modified Files
--------------
src/backend/access/transam/parallel.c |  16 ++
src/backend/storage/lmgr/README       |  63 ++++++++
src/backend/storage/lmgr/deadlock.c   | 279 +++++++++++++++++++++++++++-------
src/backend/storage/lmgr/lock.c       | 122 ++++++++++++---
src/backend/storage/lmgr/proc.c       | 158 ++++++++++++++++++-
src/include/storage/lock.h            |  13 +-
src/include/storage/proc.h            |  12 ++
7 files changed, 587 insertions(+), 76 deletions(-)

Robert Haas <rhaas@postgresql.org> writes:
> Introduce group locking to prevent parallel processes from deadlocking.

I'm fairly unhappy about this patch, because it has introduced a large
amount of new complexity into the lock manager with effectively no
documentation.  Yeah, there's several paragraphs added to lmgr/README,
but they're just a handwavy apologia for the high-level decision to allow
exclusive locks taken by parallel workers to not conflict.  I see nothing
whatever explaining how it works, that is any useful docs about the new
data structures or invariants.  For example, I can't figure out whether
you have broken the pg_locks display (by causing relevant lock state to
not get displayed, or get displayed in a useless fashion because one
can no longer tell which entries block which other entries).  I can't
even tell for sure if it works at all: the README says only that locks
taken by members of the same parallel group don't conflict, but the
implementation looks more like some operations get applied to the group
leader rather than to followers, which is something completely different.

I got here because I thought it would be interesting to see if we could
improve on isolationtester's is-it-waiting query (as suggested by Andres)
by creating a backend function to return all the PIDs that a given PID is
waiting for.  I thought this would be reasonably simple to do by crawling
the waitQueue for the lock it's blocked on.  However, I can't figure out
what impact the group locking stuff has on that.  Maybe I'm just too
stupid, but I prefer to believe this means the code is inadequately
documented.

            regards, tom lane