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. Now, that'll mean that the wal_level doesn't decrease automatically until a slot has been dropped. But that seems relatively harmless if it's not reserving WAL. Too crazy? Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
