Re: group locking: incomplete patch, just for discussion

On 15 October 2014 05:13, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)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?

Yeh. Locks should be made in the name of the main transaction and
released by it.

When my family goes to a restaurant, any member of the party may ask
for a table and the request is granted for the whole family. But the
lock is released only when I pay the bill. Once we have the table, any
stragglers know we have locked the table and they just come sit at the
table without needing to make their own lock request to the Maitre D',
though they clearly cache the knowledge that we have the table locked.

So all lock requests held until EOX should be made in the name of the
top level process. Any child process wanting a lock should request it,
but on discovering it is already held at parent level should just
update the local lock table. Transient locks, like catalog locks can
be made and released locally; I think there is more detail there but
it shouldn't affect the generalisation.

--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services