Horton

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

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

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Fujii Masao <masao.fujii@gmail.com>
Cc: Robert Haas <robertmhaas@gmail.com>, Magnus Hagander <magnus@hagander.net>, Simon Riggs <simon@2ndquadrant.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2011-03-19T00:52:37Z
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. Basic Recovery Control functions for use in Hot Standby. Pause, Resume,

Fujii Masao <masao.fujii@gmail.com> writes:
> On Fri, Mar 18, 2011 at 1:17 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>>> Sorry, I've not been able to understand the point well yet. We should
>>> just use elog(ERROR) instead? But since ERROR in startup process
>>> is treated as FATAL, I'm not sure whether it's worth using ERROR
>>> instead. Or you meant another things?

>> Yeah, I think he's saying that an ERROR in the startup process is
>> better than a FATAL, even though the effect is the same.

> We've already been using FATAL all over the recovery code. We should
> s/FATAL/ERROR/g there (at least readRecoveryCommandFile)?

Possibly, but as you say, it doesn't make that much difference in the
startup process.  What is bothering me is the prospect of elog(FATAL)
in the postmaster.  Code associated with GUC validity checking is likely
to get executed in the postmaster, which is why it should not throw
anything stronger than the normal GUC complaint levels.  Even if the
patch as proposed is for code that could only be reached in the startup
process today, somebody might decide to rearrange it ...

			regards, tom lane