| From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de>, Stephen Frost <sfrost(at)snowman(dot)net> |
| Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, Sergei Kornilov <sk(at)zsrv(dot)org>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Continue work on changes to recovery.conf API |
| Date: | 2018-11-27 08:59:26 |
| Message-ID: | ec74a8ae-8d25-6d60-1db4-907c7999acbb@2ndquadrant.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 25/11/2018 21:39, Andres Freund wrote:
> On 2018-11-25 13:24:15 -0500, Stephen Frost wrote:
>> - User performs a backup with pg_basebackup -R
>> - Replica is then promoted to be a primary
>> - User performs a backup with pg_basebackup -R on the new primary
>> - Duplicate entries end up in postgresql.auto.conf. Ew.
> Why don't we put recovery entries into postgresql.recovery.conf or such?
> And overwrite rather than append?
Adding more such sub-configuration files would be easy to do and has
some merit, but the devil is in the details. In what order would those
files be read? Who is supposed to write to it, is it reserved for
pg_basebackup use only? If you choose to use this particular name, is
it not used when not in recovery? Does this file belong in the data
directory or the configuration directory? Which choice will offend
packagers the least? Etc.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Kyotaro HORIGUCHI | 2018-11-27 08:59:49 | Re: shared-memory based stats collector |
| Previous Message | Ideriha, Takeshi | 2018-11-27 08:55:41 | RE: Protect syscache from bloating with negative cache entries |