Re: pgsql: Integrate recovery.conf into postgresql.conf

Stephen Frost <sfrost@snowman.net>

From: Stephen Frost <sfrost@snowman.net>
To: Sergei Kornilov <sk@zsrv.org>
Cc: Michael Paquier <michael@paquier.xyz>, Peter Eisentraut <peter.eisentraut@2ndquadrant.com>, Postgres hackers <pgsql-hackers@postgresql.org>
Date: 2018-11-26T17:21:18Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Integrate recovery.conf into postgresql.conf

Greetings,

* Sergei Kornilov (sk@zsrv.org) wrote:
> > I would think we'd have the different GUCs and then the check functions
> > would only validate that they're valid inputs and then when we get to
> > the point where we're starting to do recovery we check and make sure
> > we've been given a sane overall configuration- which means that only
> > *one* is set, and it matches the recovery target requested.
> How about something like attached patch?

I've not been following this very closely, but seems like
recovery_target_string is a bad idea..  Why not just make that
'recovery_target_immediate' and make it a boolean?  Having a GUC that's
only got one valid value seems really odd.

> +	if (targetSettingsCount > 1)
> +		ereport(FATAL,
> +				(errcode(ERRCODE_INVALID_PARAMETER_VALUE),
> +				 errmsg("can not specify multiple recovery targets")));

I think I would have done 'if (targetSettingsCount != 1)' here.

> -# Multiple targets
> -# Last entry has priority (note that an array respects the order of items
> -# not hashes).

You could (and imv should) include a test that throws an expected error
if multiple targets are specified.

Thanks!

Stephen