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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, Simon Riggs <simon(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Re: [COMMITTERS] pgsql: Basic Recovery Control functions for use in Hot Standby. Pause,
Date: 2011-03-19 00:52:37
Message-ID: 26832.1300495957@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

Fujii Masao <masao(dot)fujii(at)gmail(dot)com> writes:
> On Fri, Mar 18, 2011 at 1:17 AM, Robert Haas <robertmhaas(at)gmail(dot)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

In response to

Browse pgsql-committers by date

  From Date Subject
Next Message Tom Lane 2011-03-19 01:05:39 Re: pgsql: Remove ancient -X options to pg_dump, pg_dumpall, pg_restore.
Previous Message Tom Lane 2011-03-19 00:43:35 Re: pgsql: Raise maximum value of several timeout parameters

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2011-03-19 01:12:52 Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.
Previous Message Josh Berkus 2011-03-18 23:55:29 Re: 2nd Level Buffer Cache