On Tue, Aug 18, 2015 at 12:27 PM, Peter Eisentraut <peter_e@gmx.net> wrote:
> On 8/18/15 9:50 AM, Tom Lane wrote:
>> IIRC, the reason for having a wal_level parameter separate from those
>> other ones was precisely that only wal_level had to be PGC_POSTMASTER,
>> and you could change the others if you wanted.
>
> I think you are thinking of having split archive_mode/archive_command,
> so you can change archive_command at run time.
>
>> If we are going to fix
>> the mechanisms to allow dynamic changing in wal log verbosity, maybe
>> we could simply get rid of wal_level as a user-settable parameter, and
>> have its effective value be inferred from the active settings of the
>> other parameters.
>
> That would be nice, but those "other parameters" aren't really things
> that we can easily look at. In the old days, you could say that
> archive_mode = on was a pretty sure sign that you'd need wal_level =
> archive, but nowadays you can run replication without archiving. We
> could dial wal_level up and down every time someone connects to stream
> WAL, but that would surely lead to complications. Also, we have no way
> of knowing whether someone needs wal_level hot_standby until the WAL is
> on the standby and the standby decides to set hot_standby = on. The
> permutations of what could possibly influence this setting are quite
> enormous, if you consider archiving, streaming, hot standby, hot standby
> feedback, replication slots, etc., and synchronizing all of that sounds
> like a mess.
If archive_mode=on or max_wal_senders>0, then we need at least
wal_level=archive. Otherwise wal_level=minimal is enough.
If we eliminate the distinction between wal_level=archive and
wal_level=hot_standby, then we just need a way to distinguish between
hot_standby and logical.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
