Re: Re: [COMMITTERS] pgsql: Basic Recovery Control functions for use in Hot Standby. Pause,

Robert Haas <robertmhaas@gmail.com>

From: Robert Haas <robertmhaas@gmail.com>

To: Tom Lane <tgl@sss.pgh.pa.us>

Cc: Fujii Masao <masao.fujii@gmail.com>, Magnus Hagander <magnus@hagander.net>, Simon Riggs <simon@2ndquadrant.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>

Date: 2011-03-11T16:59:22Z

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 →

Basic Recovery Control functions for use in Hot Standby. Pause, Resume,
- 8c6e3adbf792 9.1.0 cited

On Fri, Mar 11, 2011 at 9:31 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Fujii Masao <masao.fujii@gmail.com> writes:
>> Yeah, since I like the former, I changed the wordings in the doc and
>> recovery.conf.sample. What about the attached patch?
>
> Please stop plastering the code with elog(FATAL) calls.  Those are
> hardly ever appropriate.  In contexts where it might be reasonable
> to do that, the error handler will treat ERROR like FATAL anyway.

Another problem here is that we are defaulting to hot_standby=off and
pause_at_recovery_target=on.  So AIUI, with this patch, if someone
sets a recovery target without making any other changes to the
configuration, their database won't start up.  That seems poor.

Even without the FATAL error, this whole pause_at_recovery_target
thing is a little weird.  If someone sets a recovery target without
making any other configuration changes, and Hot Standby is not
enabled, then we will enter normal running, but if Hot Standby *is*
enabled, then we'll replay to that point and pause recovery.  That
seems a bit confusing.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company