Re: Continue work on changes to recovery.conf API

Greetings,

On Sun, Nov 25, 2018 at 15:39 Andres Freund <andres(at)anarazel(dot)de> wrote:

> Hi,
>
> 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?

Sure, I think that’s more or less the same thing..? Another included
file, but one specifically for recovery bits.

> In the end, I'm not entirely convinced that eliminating recovery.conf is
> > actually an improvement; I think I would have rather seen the original
> > approach of having an 'auto' recovery.conf, but perhaps we can improve
> > on this since others seemed anxious to get rid of recovery.conf (though
> > I'm not sure why- seems like we'll likely end up with more code to
> > handle things cleanly with a merged recovery.auto/postgresql.auto than
> > if we had kept them independent).
>
> If we ever want to have more dynamic reconfiguration around recovery
> (say changing the primary and other settings at runtime, and a lot of
> more advanced features), we're going to need infrastructure to deal with
> that. Without the merge we'd have to duplicate the guc logic.

The recovery auto conf before was also just included into the config,
avoiding the need to have specialized handling. I do see the advantage of
having it utilize the regular GUC system, but I don’t like losing the
separation we had which allowed us to just move the whole recovery.conf to
recovery.done when we finish recovery. Seems like we could have both
though if we have the recovery options in a separately included file
instead of in PostgreSQL.auto.conf.

Thanks!

Stephen

>