Re: [HACKERS] Replication/backup defaults

On 2 January 2017 at 09:21, Magnus Hagander <magnus@hagander.net> wrote:
>
>
> On Mon, Jan 2, 2017 at 10:17 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
>>
>> On 31 December 2016 at 15:00, Magnus Hagander <magnus@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.