Re: group locking: incomplete patch, just for discussion

Robert Haas <robertmhaas@gmail.com> writes:
> For parallelism, I think we need a concept of group locking.  That is,
> suppose we have a user backend and N worker backends collaborating to
> execute some query.  For the sake of argument, let's say it's a
> parallel CLUSTER, requiring a full table lock.  We need all of the
> backends to be able to lock the table even though at least one of them
> holds AccessExclusiveLock.  This suggests that the backends should all
> be members of a locking group, and that locks within the same locking
> group should be regarded as mutually non-conflicting.

In the background worker case, I imagined that the foreground process
would hold a lock and the background processes would just assume they
could access the table without holding locks of their own.  Aren't
you building a mountain where a molehill would do?

> [1] You could argue that one process instead should take locks on
> behalf of the group.  But I think this is a terrible approach.  First,
> it means that whichever process is holding the locks, presumably the
> user backend, had better not try to do any real computation of its
> own, so that it can timely service lock requests, which seems like a
> huge loss of efficiency;

What is "timely service lock requests"?  You got the lock before firing
off the background workers, you hold it till they're done.

This is a truly horrible excuse for the amount of complexity (and,
without doubt, bugs and performance penalties) you propose to load onto
the lock mechanism.
        regards, tom lane