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 →
-
Integrate recovery.conf into postgresql.conf
- 2dedf4d9a899 12.0 cited
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