Re: Idea for fixing parallel pg_dump's lock acquisition problem - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Idea for fixing parallel pg_dump's lock acquisition problem
Date
Msg-id 28542.1555709686@sss.pgh.pa.us
Whole thread Raw
In response to Re: Idea for fixing parallel pg_dump's lock acquisition problem  (Julien Rouhaud <rjuju123@gmail.com>)
List pgsql-hackers
Julien Rouhaud <rjuju123@gmail.com> writes:
> On Fri, Apr 19, 2019 at 7:17 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> 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?

Um, no, because there's no way for pg_dump to get at it in existing
server releases.  The only available feature that supports mid-transaction
unlock is the advisory-lock stuff.

If we have to add new code, we could perfectly well add another
LockTagType to go with it.  But that doesn't really solve the problem.
Whatever SQL API we provide would have to be available to everybody
(since pg_dump doesn't necessarily run as superuser), and as soon as
somebody says "hey that's a neat feature, I think I'll use it in my
app" we're back to square one.  It's not very apparent how we could
have a lock tag that's available to pg_dump processes and nobody else.

I had some vague ideas about making it depend on the processes sharing
a snapshot; but it's not obvious how to get from there to a suitable
locktag, and in any case that certainly wouldn't be pre-existing
server functionality.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Julien Rouhaud
Date:
Subject: Re: Idea for fixing parallel pg_dump's lock acquisition problem
Next
From: Stephen Frost
Date:
Subject: Re: block-level incremental backup