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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Idea for fixing parallel pg_dump's lock acquisition problem
Дата
Msg-id 28542.1555709686@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Idea for fixing parallel pg_dump's lock acquisition problem  (Julien Rouhaud <rjuju123@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Julien Rouhaud
Дата:
Сообщение: Re: Idea for fixing parallel pg_dump's lock acquisition problem
Следующее
От: Stephen Frost
Дата:
Сообщение: Re: block-level incremental backup