Re: allowing wal_level change at run time

On Tue, Aug 18, 2015 at 7:46 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:

> On 2015-08-18 13:24:54 -0400, Peter Eisentraut wrote:
> > On 8/18/15 12:35 PM, Robert Haas wrote:
> > > If archive_mode=on or max_wal_senders>0, then we need at least
> > > wal_level=archive. Otherwise wal_level=minimal is enough.
> >
> > Totally forgot about max_wal_senders.
> >
> > However, the thread I linked to earlier aimed for a different master
> > plan (or if not, I'm aiming for it now). There is camp 1, which wants
> > to keep all the defaults the same, for "performance" or something like
> > that. And there is camp 2, which wants to have a replication-friendly
> > setup by default. Instead of fighting over this, your idea was to be
> > able to switch between 1 and 2 easily (which means in particular without
> > restarts).
>
> I don't think not requiring restarts is sufficient, having to twiddle a
> bunch of parameters manually still is a lot more effort than people see
> as necessary.
>
> The only reason I think changing the default is a good approach is that
> it's doable within a relatively short amount of time.
>
> > But if we tie the effective wal_level to archive_mode or
> > max_wal_senders, both of which are restart-only, then we haven't gained
> > anything. (We would have removed half a GUC parameter, effectively.
> > Not bad, but not very exciting.)
>
> ISTM that it's not too hard to
> a) make archive_mode PGC_SIGHUP
> b) make wal_level PGC_SIGHUP
> c) automatically increase wal_level to logical whenever a logical
> replication slot is defined
>
> it seems considerably harder to
>
> d) make max_wal_senders PGC_SIGHUP
> e) make max_replication_slots PGC_SIGHUP
>
> because they need shmem, locks, and everything.
>
>
> Therefore I propose something slightly different:
>
> We change the default of max_wal_senders, max_replication_slots, to some
> reasonably high setting and make wal_level an internal automagically
> determined variable. archive_mode = on automatically increases the level
> to what's now hot-standby.
>
> To deal with streaming replication, we automatically create slots for
> replicas, but, by default, *without* having them reserve WAL. The slot
> name would be determined in some automatic fashion (uuid or something)
> and stored in a new file in the data directory. That allows us to
> increase the internal wal_level to hot_standby/archive whenever a
> replica has connected (and thus a physical slot exists), and to logical
> whenever a logical slot exists.
>

What happens "the first time"? Meaning I'm on wal_level=minimal and take a
base backup. Then when the replica first connects 10 minutes later, it
needs WAL back in time, which was logged at wal_level=minimal.

So you'd need to bump it up whenever a base backup is done -- but then you
can't drop it back down again or your base backup will be useless.

Or am I missing something?

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/