Re: pg_basebackups and slots

On Fri, Dec 16, 2016 at 12:41 PM, Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com
> wrote:

> On 16/12/16 07:32, Magnus Hagander wrote:
> >
> > On Dec 16, 2016 07:27, "Michael Paquier" <michael(dot)paquier(at)gmail(dot)com
> > <mailto:michael(dot)paquier(at)gmail(dot)com>> wrote:
> >
> >
> >
> > On Thu, Dec 15, 2016 at 7:28 PM, Magnus Hagander
> > <magnus(at)hagander(dot)net <mailto:magnus(at)hagander(dot)net>> wrote:
> > > So here's a patch that does this, for discussion. It implements the
> > > following behavior for -X:
> > >
> > > * When used with <10.0 servers, behave just like before.
> > > * When -S <name> is specified, behave just like before (use an
> > existing
> > > replication slot, fail if it does not exist)
> > > * When used on 10.0 with no -S, create and use a temporary
> > replication slot
> > > while running, with name pg_basebackup_<pid>.
> > > * When used with 10.0 with no -S but --no-slot specified, run
> > without a slot
> > > like before.
> >
> > There are users using -X stream without a slot now because they
> > don't want to
> > cause WAL retention in pg_xlog and are ready for retries in taking
> > the base
> > backup... I am wondering if it is a good idea to change the default
> > behavior
> > and not introduce a new option like --temporary-slot, or
> > --slot-mode=temp|persistent|none with none being the default
> > instead. There
> > are users caring about pg_xlog not filling up if pg_basebackup hangs
> > on write
> > for example. And it may be a good idea to be able to use
> > --slot-mode=temp
> > with -S/--slot actually to allow users to monitor it. If no slot
> > name is given
> > with --slot generating one looks fine to me.
> >
> >
> > I really think the default should be "what most people want", and not
> > "whatever is compatible with a mode that was necessary because we lacked
> > infrastructure".
>
> +1 (btw glad you made the patch)
>

I'm glad you made the temp slots, so I could abandon that branch :)

> > Yes there are some people who are fine with their backups failing. I'm
> > willing to say there are *many* more who benefit from an automatic slot.
> >
>
> I think the issue with slots taking over disk space should be fixed by
> making it possible to cut off slots when necessary (ie some GUC that
> would say how much behind slot can be at maximum, with something like 0
> being unlimited like it's now) instead of trying to work around that in
> every client.
>

Agreed, that seems like a better solution.

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/