Re: Idea for fixing parallel pg_dump's lock acquisition problem

On Fri, Apr 19, 2019 at 7:17 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> > On Wed, Apr 17, 2019 at 11:34 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >> ... If there are user applications
> >> running that also use advisory locks, there could be unwanted
> >> interference. One easy improvement is to use pg_try_advisory_lock(k) in
> >> step 2, and just choose a different k if the lock's in use. Perhaps,
> >> since we don't expect that the locks would be held long, that's
> >> sufficient --- but I suspect that users might wish for some pg_dump
> >> options to restrict the set of keys it could use.
>
> > This seems like a pretty significant wart. I think we probably need a
> > better solution, but I'm not sure what it is. I guess we could define
> > a new lock space that is specifically intended for this kind of
> > inter-process coordination, where it's expected that the key is a PID.
>
> My thought was that we'd like this to work without requiring any new
> server-side facilities, so that pg_dump could use it against any server
> version that supports parallel dump.

Couldn't we use LOCKTAG_USERLOCK for that? It should be compatible
with all needed server versions, and the odds of collision seem low as
the extension as been dropped in pg 8.2 and the pgfoundry project has
no activity since 2006. I'm not aware of any other extension using
it, and a quick search didn't find anything.