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

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

In response to

Browse pgsql-hackers by date

  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