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-26T21:22:53Z

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'd encourage you to look through the diff after you're finished hacking
> > before sending it to the list, in case things get left in that should be
> > removed, as below...
> I am so sorry. I have a look before sending, but...
> It's night in my timezone. I will fix tomorrow.

Sure, I don't think there's any need to rush any of this.

> >>  + if (targetSettingsCount > 1)
> >>  + ereport(FATAL,
> >>  + (errcode(ERRCODE_INVALID_PARAMETER_VALUE),
> >>  + errmsg("can not specify multiple recovery targets")));
> >
> > Doesn't look like you changed this based on my prior comment..?
> Do you mean this one?
> > I think I would have done 'if (targetSettingsCount != 1)' here.
> To be sure, we need check we have one recovery target without standby mode and none or one in standby mode? Or some another check?

Right, I think that's what the idea was, although that might require
something for the explicit 'recover to the end case', now that I think
about it, so perhaps the >1 isn't so bad.  Still seems a bit odd to me
though and I do wonder if there might be a better approach.

Thanks!

Stephen