From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Julien Rouhaud <rjuju123(at)gmail(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Idea for fixing parallel pg_dump's lock acquisition problem |
Date: | 2019-04-19 21:34:46 |
Message-ID: | 28542.1555709686@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Julien Rouhaud <rjuju123(at)gmail(dot)com> writes:
> On Fri, Apr 19, 2019 at 7:17 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2019-04-20 00:04:41 | Re: block-level incremental backup |
Previous Message | Julien Rouhaud | 2019-04-19 20:52:08 | Re: Idea for fixing parallel pg_dump's lock acquisition problem |