Re: [HACKERS] Defaults for replication/backup

On Sun, Apr 24, 2016 at 5:50 PM, Tom Lane wrote: > Magnus Hagander writes: > > On Thu, Apr 21, 2016 at 7:20 PM, Robert Haas > wrote: > >> I think we are far too close to beta1 to begin bikeshedding this. > >> Changing the defaults

Re: [HACKERS] Defaults for replication/backup

Magnus Hagander writes: > On Thu, Apr 21, 2016 at 7:20 PM, Robert Haas wrote: >> I think we are far too close to beta1 to begin bikeshedding this. >> Changing the defaults is not going to be uncontroversial, and it's not >> something I think we should

Re: [HACKERS] Defaults for replication/backup

On Thu, Apr 21, 2016 at 7:20 PM, Robert Haas wrote: > On Wed, Apr 20, 2016 at 2:04 PM, Magnus Hagander > wrote: > > So what more do we need to just get going with this? Given feature freeze > > we're perhaps too late to actually build the parameter

Re: [HACKERS] Defaults for replication/backup

On Wed, Apr 20, 2016 at 2:04 PM, Magnus Hagander wrote: > So what more do we need to just get going with this? Given feature freeze > we're perhaps too late to actually build the parameter feature for initdb, > but we could still change the defaults (and then we could add

Re: [HACKERS] Defaults for replication/backup

On Sun, Feb 14, 2016 at 9:58 AM, Magnus Hagander wrote: > > > On Sun, Feb 14, 2016 at 2:00 AM, Robert Haas > wrote: > >> On Sat, Feb 13, 2016 at 11:31 AM, Andres Freund >> wrote: >> > On 2016-02-13 11:10:58 -0500, Tom Lane wrote:

Re: [HACKERS] Defaults for replication/backup

On Sun, Feb 14, 2016 at 2:00 AM, Robert Haas wrote: > On Sat, Feb 13, 2016 at 11:31 AM, Andres Freund > wrote: > > On 2016-02-13 11:10:58 -0500, Tom Lane wrote: > >> Magnus Hagander writes: > >> > The big thing is, IIRC, that we

[HACKERS] Defaults for replication/backup

I know we've had many discussions about the defaults, so hey, let's bring out the paint-cans and do the bikeshed all over again. I would suggest a couple of changes to the default values in parameters related to backup and replication. The reason for this is to make it "easier to do the right

Re: [HACKERS] Defaults for replication/backup

On Sat, Feb 13, 2016 at 10:15 PM, Magnus Hagander wrote: > So, I suggest the following changes to the defaults: > wal_level=hot_standby > max_wal_senders=10 > max_replication_slots=10 10 seems a bit high. I would think that max_wal_senders and max_replication_slots set at 3 are sufficient enough,

Re: [HACKERS] Defaults for replication/backup

On 2016-02-13 22:37:33 +0900, Michael Paquier wrote: > On Sat, Feb 13, 2016 at 10:15 PM, Magnus Hagander wrote: > > So, I suggest the following changes to the defaults: > > wal_level=hot_standby > > max_wal_senders=10 > > max_replication_slots=10 +1. I'm inclined to set slots a bit higher than

Re: [HACKERS] Defaults for replication/backup

On Sat, Feb 13, 2016 at 2:39 PM, Andres Freund wrote: > On 2016-02-13 22:37:33 +0900, Michael Paquier wrote: > > On Sat, Feb 13, 2016 at 10:15 PM, Magnus Hagander wrote: > > > So, I suggest the following changes to the defaults: > > > wal_level=hot_standby > > >

Re: [HACKERS] Defaults for replication/backup

On 02/13/2016 05:37 AM, Michael Paquier wrote: On Sat, Feb 13, 2016 at 10:15 PM, Magnus Hagander wrote: So, I suggest the following changes to the defaults: wal_level=hot_standby max_wal_senders=10 max_replication_slots=10 10 seems a bit high. I would think that max_wal_senders and

Re: [HACKERS] Defaults for replication/backup

Hello, I would like to add the idea of having archiving on by default. Not everyone uses streaming replication, some people use PITR. The one that I see is archive_command and I am not sure how to deal with that. Sincerely, JD -- Command Prompt, Inc.

Re: [HACKERS] Defaults for replication/backup

Hi, On 2016-02-13 07:13:55 -0800, Joshua D. Drake wrote: > I would like to add the idea of having archiving on by default. Not everyone > uses streaming replication, some people use PITR. The one that I see is > archive_command and I am not sure how to deal with that. Since that requires

Re: [HACKERS] Defaults for replication/backup

On Sat, Feb 13, 2016 at 4:16 PM, Andres Freund wrote: > Hi, > > On 2016-02-13 07:13:55 -0800, Joshua D. Drake wrote: > > I would like to add the idea of having archiving on by default. Not > everyone > > uses streaming replication, some people use PITR. The one that I see is

Re: [HACKERS] Defaults for replication/backup

Magnus Hagander writes: > Yes, these changes will increase some of the default overhead. My argument > against that is that anybody who actually cares about that overhead is > going to be tuning their database *anyway*, so they can just change things > back to the old

Re: [HACKERS] Defaults for replication/backup

On Sat, Feb 13, 2016 at 4:52 PM, Tom Lane wrote: > Magnus Hagander writes: > > Yes, these changes will increase some of the default overhead. My > argument > > against that is that anybody who actually cares about that overhead is > > going to be tuning

Re: [HACKERS] Defaults for replication/backup

Magnus Hagander writes: > On Sat, Feb 13, 2016 at 4:52 PM, Tom Lane wrote: >> It would be easier to sell this if we had some numbers for the amount of >> overhead it would add for people *not* using the features. I do not think >> I've ever seen, eg,

Re: [HACKERS] Defaults for replication/backup

On 2016-02-13 11:10:58 -0500, Tom Lane wrote: > Magnus Hagander writes: > > The big thing is, IIRC, that we turn off the optimizations in > > min_wal_level. *most* people will see no impact of their regular > > application runtime from that, but it might definitely have an

Re: [HACKERS] Defaults for replication/backup

On Sat, Feb 13, 2016 at 11:31 AM, Andres Freund wrote: > On 2016-02-13 11:10:58 -0500, Tom Lane wrote: >> Magnus Hagander writes: >> > The big thing is, IIRC, that we turn off the optimizations in >> > min_wal_level. *most* people will see no impact of