On 2 January 2017 at 09:21, Magnus Hagander <mag...@hagander.net> wrote: > > > On Mon, Jan 2, 2017 at 10:17 AM, Simon Riggs <si...@2ndquadrant.com> wrote: >> >> On 31 December 2016 at 15:00, Magnus Hagander <mag...@hagander.net> wrote: >> > Cycling back to this topic again, but this time at the beginning of a >> > CF. >> > >> > Here's an actual patch to change: >> > >> > >> > max_wal_senders=10 >> > max_replication_slots=20 >> >> +1 >> >> If that doesn't fly, it seems easy enough to introduce a >> "min_reserve_limit" GUC that defaults to 10 that gives a lower bound >> on the amount of memory we reserve for many of those shmem allocs; >> that can be set to 0 for people that want the old behaviour. Then we >> can allow changes up to the memory limit without a restart. >> >> > wal_level=replica >> >> This is more problematic because it changes behaviours. > > > You can't actually change the other two without changing wal_level.
You could, but we currently disallow it. >> A more useful approach would be to bring all the things needed to >> enable replication into one ALTER SYSTEM command, so people have just >> one thing they need to execute and it will work out the details and >> locations for you. >> That way we can maintain the defaults yet make it easier to enable in >> a useful way. > > > Sure, that would be great - the core being the ability to change these > things without a restart. But I would argue for not letting perfection get > in the way of progress, and do this anyway. I doubt there is any way the > bigger change is going to get done for 10 at this point, so we should give > people the ability to do backups off a default installation already. We could fairly easily change wal_level without restart; its been discussed for many years. The problem from my perspective is that you're immediately turning off the performance benefits for initial bulk loads. Arguing how that isn't a problem looks at least as time consuming as fixing the problem. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
