Re: Re: Continue work on changes to recovery.conf API

From: David Steele <david(at)pgmasters(dot)net>
To: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, 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: Re: Continue work on changes to recovery.conf API
Date: 2019-02-28 15:38:13
Message-ID: 22e9d0a9-fbc2-4a72-af7f-b8a6bc0fd822@pgmasters.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 11/27/18 4:36 PM, Peter Eisentraut wrote:
> On 27/11/2018 13:21, David Steele wrote:
>> I would prefer a specific file that will be auto-included into
>> postgresql.conf when present but be ignored when not present. Some
>> settings are generally ephemeral (recovery_target_time) and it would be
>> nice for them to go away. When recovery is complete the file would be
>> renamed to .done just as recovery.conf is now.
>
> That might be a useful facility, but it wouldn't really address the
> pg_basebackup -R issue, because that creates settings that you don't
> want going away in this manner. You'd then need two separate such
> files, one for targeted recovery that goes away when recovery ends, and
> one that is automatically included that pg_basebackup can overwrite at will.

I'm not sure why that's true. Some settings you might prefer to be
persistent and others not. If pg_basebackup -R is treating them the
same then that seems like a limitation.

Endlessly appending settings into postgresql.auto.conf seems confusing
even if it makes sense to postgres (i.e. last setting wins).

Regards,
--
-David
david(at)pgmasters(dot)net

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message David Steele 2019-02-28 15:41:19 Re: Re: Continue work on changes to recovery.conf API
Previous Message Robert Haas 2019-02-28 15:35:50 Re: Drop type "smgr"?