Re: Getting rid of wal_level=archive and default to hot_standby + wal_senders

On 03/02/15 13:51, Magnus Hagander wrote:
> On Tue, Feb 3, 2015 at 1:43 PM, Andres Freund <andres@2ndquadrant.com
> <mailto:andres@2ndquadrant.com>> wrote:
>
>     Hi,
>
>     I think these days there's no reason for the split between the archive
>     and hot_standby wal levels. The split was made out of volume and
>     stability concerns. I think we can by now be confident about the
>     wal_level = hot_standby changes (note I'm not proposing hot_standby =
>     on).
>
>     So let's remove the split. It just gives users choice between two
>     options
>     that don't have a meaningful difference.
>
>
> +1.
>

+1 too

>
>     Additionally I think we should change the default for wal_level to
>     hot_standby and max_wal_senders (maybe to 5). That way users can use
>     pg_basebackup and setup streaming standbys without having to restart the
>     primary. I think that'd be a important step in making setup easier.
>
>
> Yes, please!
>
> Those who want to optimize their WAL size can set it back to minimal,
> but let's make the default the one that makes life *easy* for people.
>
> The other option, which would be more complicated (I have a
> semi-finished patch that I never got time to clean up) would be for
> pg_basebackup to be able to dynamically raise the value of wal_level
> during it's run. It would not help with the streaming standby part, but
> it would help with pg_basebackup. That could be useful independent - for
> those who prefer using wal_level=minimal and also pg_basebackup..
>
>

This is not that easy to do, let's do it one step at a time.

>
>     Comments?
>
>     Additionally, more complex and further into the future, I wonder if we
>     couldn't also get rid of wal_level = logical by automatically switching
>     to it whenever logical slots are active.
>
>
>
> If it can be safely done online, I definitely think that would be a good
> goal to have. If we could do the same for hot_standby if you had
> physical slots, that might also be a good idea?
>

+many for the logical, physical would be nice but I think it's again in 
the category of not so easy and maybe better as next step if at all.

--  Petr Jelinek                  http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training &
Services