Re: allowing wal_level change at run time

On 8/19/15 9:32 AM, Andres Freund wrote:
>> I agree that we want both.  But requiring a restart is a hard stop,
>> whereas making configuration easier is a soft feature.
> 
> I don't think it makes that much of a difference for people new to
> postgres.

People new to postgres are not the only audience for this change.

>>> 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.
>>
>> That seems kind of weird.  So every time a replication client connects,
>> we create a new replication slot?  Won't they accumulate?
> 
> No, that's not what I was thinking of. The name of the slot would be
> stored somewhere in the data directory, and then be reused henceforth.

It seems to me that this would effectively replace the wal_level
parameter with the presence or absence of a magic replication slot.
That doesn't seem like a net improvement.  It just replaces one
well-known configuration mechanism with a new ad hoc one.

>> Also note that this scheme and any similar one requires merging the
>> archive and hot_standby levels, which was the core of your original
>> proposal [1]
> 
> It doesn't really, we could continue to keep them separate. I'm
> proposing to maintain wal_level automatically, so it'd not be
> configurable anymore, so it'd not matter much, as long as we're not less
> efficient.

But, under any scheme to set wal_level automatically, how will the
primary know whether it needs to use level archive or hot_standby?
There is no way to know.  So if we are going to keep these levels
separate, there would need to be a manual way to switch between them.