On Fri, Dec 16, 2016 at 12:41 PM, Petr Jelinek <petr.jeli...@2ndquadrant.com > wrote:
> On 16/12/16 07:32, Magnus Hagander wrote: > > > > On Dec 16, 2016 07:27, "Michael Paquier" <michael.paqu...@gmail.com > > <mailto:michael.paqu...@gmail.com>> wrote: > > > > > > > > On Thu, Dec 15, 2016 at 7:28 PM, Magnus Hagander > > <mag...@hagander.net <mailto:mag...@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) > 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/
