Re: allowing wal_level change at run time

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: allowing wal_level change at run time
Date: 2015-08-20 19:11:02
Message-ID: 55D62646.2010306@gmx.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jim Nasby 2015-08-20 19:16:22 Re: proposal: function parse_ident
Previous Message Peter Geoghegan 2015-08-20 17:41:36 Re: Using quicksort for every external sort run