Re: [HACKERS] pg_basebackups and slots
От | Michael Paquier |
---|---|
Тема | Re: [HACKERS] pg_basebackups and slots |
Дата | |
Msg-id | 20161216062750.GC17838@paquier.xyz обсуждение исходный текст |
Ответ на | Re: [HACKERS] pg_basebackups and slots (Magnus Hagander <magnus@hagander.net>) |
Список | pgsql-hackers |
On Thu, Dec 15, 2016 at 7:28 PM, Magnus Hagander <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. Regarding the patch, it would be good to add a set of TAP tests to cover the new features. I am not seeing anything badly wrong with it at first sight by the way. -- Michael
В списке pgsql-hackers по дате отправления: