Re: allowing wal_level change at run time

On 2015-08-18 21:47:51 -0400, Peter Eisentraut wrote:
> On 8/18/15 1:46 PM, Andres Freund wrote:
> > 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.
>
> 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.

> > 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.

> Do we need the replication slot, or could we just trigger this on the
> existence of a replication client?

I don't think that can work, because a replication connection obviously
can go away temporarily. If we'd then fall back to wal_level minimal the
standby would be cut off.

> 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.

> , which was then objected to, which subsequently lead to
> Robert's proposal to make wal_level SIGHUP, which lead to my message,
> which lead to your message, which is similar to your initial one.
> Somehow we have to find a way break out of this circle. ;-)

My reading of the objections was that it was primarily about increasing
the amount of WAL in the default configuration, and this proposal
wouldn't anymore. An out-of-the-box configuration wouldn't emit more WAL
than today, until it's been used with streaming rep.

Greetings,

Andres Freund