Re: [HACKERS] pg_basebackups and slots

On Mon, Jan 16, 2017 at 4:33 PM, Fujii Masao wrote: > On Mon, Jan 16, 2017 at 10:00 PM, Magnus Hagander > wrote: > > > > > > On Wed, Jan 4, 2017 at 3:32 PM, Peter Eisentraut > > wrote: > >> > >> This patch looks reasonable to me. > >> > >> Attached is a top-up patch with a few small fixups. > >

Re: [HACKERS] pg_basebackups and slots

On Mon, Jan 16, 2017 at 10:00 PM, Magnus Hagander wrote: > > > On Wed, Jan 4, 2017 at 3:32 PM, Peter Eisentraut > wrote: >> >> This patch looks reasonable to me. >> >> Attached is a top-up patch with a few small fixups. >> >> I suggest to wait for the resolution of the "Replication/backup >> defa

Re: [HACKERS] pg_basebackups and slots

On Wed, Jan 4, 2017 at 3:32 PM, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > This patch looks reasonable to me. > > Attached is a top-up patch with a few small fixups. > > I suggest to wait for the resolution of the "Replication/backup > defaults" thread. I would not want to be i

Re: [HACKERS] pg_basebackups and slots

This patch looks reasonable to me. Attached is a top-up patch with a few small fixups. I suggest to wait for the resolution of the "Replication/backup defaults" thread. I would not want to be in a situation where users who have not been trained to use replication slots now have yet another resta

Re: [HACKERS] pg_basebackups and slots

On 12/17/16 9:55 AM, Magnus Hagander wrote: > That makes a lot of sense now that we have temporary replication slots, > I agree. And then max_replication_slots could be something like > persistent_replication_slots? I was thinking was more like that each walsender gets one fixed slot, which can be

Re: [HACKERS] pg_basebackups and slots

On Sat, Dec 17, 2016 at 3:54 PM, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > On 12/15/16 4:04 AM, Magnus Hagander wrote: > > This obviously requires the server to be configured with enough slots (I > > still think we should change the default here, but that's a different > > topi

Re: [HACKERS] pg_basebackups and slots

On Fri, Dec 16, 2016 at 7:40 AM, Michael Paquier wrote: > On Fri, Dec 16, 2016 at 3:32 PM, Magnus Hagander > wrote: > > I don't really know how to write a good test for it. I mean, we could > run it > > with the parameter, but how to we make it actually verify the slot? Make > a > > really big d

Re: [HACKERS] pg_basebackups and slots

On 12/15/16 4:04 AM, Magnus Hagander wrote: > This obviously requires the server to be configured with enough slots (I > still think we should change the default here, but that's a different > topic), but I think that's acceptable. We could implicitly reserve one replication slot per walsender. A

Re: [HACKERS] pg_basebackups and slots

On Fri, Dec 16, 2016 at 12:41 PM, Petr Jelinek wrote: > On 16/12/16 07:32, Magnus Hagander wrote: > > > > On Dec 16, 2016 07:27, "Michael Paquier" > > wrote: > > > > > > > > On Thu, Dec 15, 2016 at 7:28 PM, Magnus Hagander > > mailto:mag...@hagander.net>

Re: [HACKERS] pg_basebackups and slots

On 16/12/16 07:32, Magnus Hagander wrote: > > On Dec 16, 2016 07:27, "Michael Paquier" > wrote: > > > > On Thu, Dec 15, 2016 at 7:28 PM, Magnus Hagander > mailto:mag...@hagander.net>> wrote: > > So here's a patch that does this, for discussion. It

Re: [HACKERS] pg_basebackups and slots

On Fri, Dec 16, 2016 at 3:32 PM, Magnus Hagander wrote: > I don't really know how to write a good test for it. I mean, we could run it > with the parameter, but how to we make it actually verify the slot? Make a > really big database to make it guaranteed to be slow enough that we can > notice it

Re: [HACKERS] pg_basebackups and slots

At 2016-12-16 07:32:24 +0100, mag...@hagander.net wrote: > > 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". Very much agreed. -- Abhijit -- Sent via pgsql-hackers mailing list (

Re: [HACKERS] pg_basebackups and slots

On Dec 16, 2016 07:27, "Michael Paquier" wrote: On Thu, Dec 15, 2016 at 7:28 PM, Magnus Hagander 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 is specified, beh

Re: [HACKERS] pg_basebackups and slots

On Thu, Dec 15, 2016 at 7:28 PM, Magnus Hagander 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 is specified, behave just like before (use an existing > replicatio

Re: [HACKERS] pg_basebackups and slots

> but -X stream is, then we use a temporary slot always. This seems even more useful with -X fetch to me, as with fetch we are sure we are not immediately receiving the WAL. So, I'd propose to use it whenever -X is specified, regardless of which method is specified. > (I still think we should chan

Re: [HACKERS] pg_basebackups and slots

On Thu, Dec 15, 2016 at 10:26 AM, Magnus Hagander wrote: > > > On Thu, Dec 15, 2016 at 10:04 AM, Magnus Hagander > wrote: > >> I've started work on a patch to make pg_basebackup use the temporary >> slots feature that has been committed (thanks Petr!!). The reason for this >> is to avoid the ca

Re: [HACKERS] pg_basebackups and slots

On Thu, Dec 15, 2016 at 10:04 AM, Magnus Hagander wrote: > I've started work on a patch to make pg_basebackup use the temporary slots > feature that has been committed (thanks Petr!!). The reason for this is to > avoid the cases where a burst of traffic on the master during the backup > can caus

[HACKERS] pg_basebackups and slots

I've started work on a patch to make pg_basebackup use the temporary slots feature that has been committed (thanks Petr!!). The reason for this is to avoid the cases where a burst of traffic on the master during the backup can cause the receive log part of the basebackup to fall far enough behind