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