Re: behave of --create-slot option

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Euler Taveira <euler(at)timbira(dot)com(dot)br>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, Robert Haas <robertmhaas(at)gmail(dot)com>, Craig Ringer <craig(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: behave of --create-slot option
Date: 2018-06-01 16:38:52
Message-ID: CAFj8pRDLXGomhX3Tfep946On4JiHdM5scA-ey2mJoG4Hr_+g2w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2018-06-01 18:36 GMT+02:00 Euler Taveira <euler(at)timbira(dot)com(dot)br>:

> 2018-06-01 9:00 GMT-03:00 Michael Paquier <michael(at)paquier(dot)xyz>:
> > 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(at)paquier(dot)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.
> >
> Debian and derivatives put pg_basebackup in the client package
> (indeed, it a client program). A possible fix is to drop the slot if
> there is an error. However, if the problem is connectivity, we can't
> drop it. In this case, we can print a user-friendly error saying that
> the user should drop that slot before try again). If we follow this
> idea, then I consider it to be a bug fix.
>
> > 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.
> >
> I don't like it. You should send an extra command to recover from an
> error. It also does not follow the idempotent behavior. I know that
> you are trying to mimic pg_receivewal options but I prefer another
> option that removes the slot if it exists (say,
> --drop-slot-if-exists). In this case, I consider this option as new
> development.
>
>
+1

Pavel

> --
> Euler Taveira Timbira -
> http://www.timbira.com.br/
> PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Chris Wilson 2018-06-01 16:46:48 Re: Possible optimisation: push down SORT and LIMIT nodes
Previous Message Euler Taveira 2018-06-01 16:36:55 Re: behave of --create-slot option