Re: [HACKERS] Replication/backup defaults

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.

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.

> Based on feedback from last year
> (https://www.postgresql.org/message-id/CABUevEwfV7zDutescm2PHGvsJdYA0RWHFMTRGhwrJPGgSbzZDQ%40mail.gmail.com):
>
>
> There were requests for benchmarks of performance difference. Tomas has
> promised to run a couple of benchmarks on his standard benchmarking setups
> to give numbers on that. Thanks Tomas, please pipe in with your results when
> you have them!
>
>
> Security considerations about pg_hba.conf -- I avoided those by not actually
> changing pg_hba.conf. Since pg_hba.conf can be changed on a reload instead
> of a restart it's a lot easier to deal with. I still think changing it to
> allow "postgres" the same type of connections  as it does for regular users
> would not be a security problem, but again thanks to it only needing a
> reload it's not as big an issue.
>
>
> There was the idea to have multiple sets of defaults to choose from at
> initdb time. I don't see a problem having that, but it's been another year
> and nobody built it. I don't think not having that is an excuse for the
> current defaults. And implementing something like that is in no way hindered
> by
> changing the current defaults.
>
> We were too close to beta1 -- this is why I'm sending it earlier this time
> :) (Even though I intended to do it already back in September, better now
> than even later)
>
> Finally, there's the argument that we're already shaking up a number of
> other things with version 10, so this is a good time to do this one as well.
>
> --
>  Magnus Hagander
>  Me: http://www.hagander.net/
>  Work: http://www.redpill-linpro.com/
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>



-- 
Simon Riggs                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services