On 16/12/16 07:32, Magnus Hagander wrote:
>
> On Dec 16, 2016 07:27, "Michael Paquier" <michael.paquier@gmail.com
> <mailto:michael.paquier@gmail.com>> wrote:
>
>
>
> On Thu, Dec 15, 2016 at 7:28 PM, Magnus Hagander
> <magnus@hagander.net <mailto:magnus@hagander.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)
>
> 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.
-- Petr Jelinek http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training &
Services