| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
| Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: allowing wal_level change at run time |
| Date: | 2015-08-18 12:48:42 |
| Message-ID: | CA+Tgmob11z9d5RTxrTCqUaJWuZboTv93C_mEj0eHC54EDnq+PQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Greg Stark | 2015-08-18 13:03:19 | Re: Test code is worth the space |
| Previous Message | Magnus Hagander | 2015-08-18 12:04:21 | Re: allowing wal_level change at run time |