Re: behave of --create-slot option

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: behave of --create-slot option
Дата
Msg-id 20180601120036.GA9004@paquier.xyz
обсуждение исходный текст
Ответ на Re: behave of --create-slot option  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: behave of --create-slot option  (Euler Taveira <euler@timbira.com.br>)
Список pgsql-hackers
On Thu, May 31, 2018 at 10:59:04PM -0400, Robert Haas wrote:
> On Wed, May 30, 2018 at 2:00 PM, Michael Paquier <michael@paquier.xyz> wrote:
>> Hm.  There could be an argument for improving the user experience here
>> so as some cleanup is at least attempted except if --no-clean is defined
>> by the caller when --create-slot is used.  Do we want an open item for
>> this issue?
>
> Sounds like new development to me.  This isn't a bug.

Still, it seems to me that the user experience is a bit horrible with
this new interface of pg_basebackup.  If --create-slot is used, then a
slot is created before starting a backup.  If the slot already exists,
then pg_basebackup complains and exits.  In order to drop the slot with
a only user who has replication access rights (because nobody is really
going to have a user who has SQL access so as the slot is dropped), then
the only simple way is to use pg_receivewal --drop-slot, making the
whole flow inconsistent.  pg_basebackup is usually in server-side
packages, and pg_receivewal is on the client side.  The server packages
requiring the client packages, then we are sure that pg_basebackup will
drag in pg_receivewal.

Still, shouldn't there be a --drop-slot option in pg_basebackup?  In
this case, if --drop-slot is used, then the slot is dropped and
pg_basebackup exits immediately.
--
Michael

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Christopher Wilson
Дата:
Сообщение: FW: Possible optimisation: push down SORT and LIMIT nodes
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: Loaded footgun open_datasync on Windows