From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: allowing wal_level change at run time |
Date: | 2015-08-18 13:41:14 |
Message-ID: | 55D335FA.3050209@gmx.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 8/18/15 8:48 AM, Robert Haas wrote:
> On Tue, Aug 18, 2015 at 7:59 AM, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
>> How would we handle decreases at run time? We can prevent >=archive ->
>> minimal if archiving is running or there are physical replication slots,
>> and we can prevent logical -> something less if there are logical
>> replication slots, but AFAICT, we don't have a way to check whether
>> anyone currently needs level hot_standby.
>
> What do you mean by "prevent"? If the user edits postgresql.conf and
> reduces the setting, and then reloads the configuration file, they
> have a right to expect that the changes got applied.
We have certain checks in place that require a minimum wal_level before
other things are allowed. For example, turning on archiving requires
wal_level >= archive. The issue is then, if you have archiving on and
then turn wal_level to minimal at run time, we need to prevent that to
preserve the integrity of the original check.
From | Date | Subject | |
---|---|---|---|
Next Message | David Fetter | 2015-08-18 13:43:23 | Re: Declarative partitioning |
Previous Message | Robert Haas | 2015-08-18 13:19:12 | Re: Warnings around booleans |