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

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. If we're willing to restrict
the fix to server >= v13, or whenever this gets done, then yes we could
(probably) arrange things to avoid the hazard. I'm not quite sure how
it'd work though. We can't just invent a process-local key space,
because both the master and worker need to be able to lock the same
key.

regards, tom lane