Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
Lists: pgsql-committerspgsql-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

pgsql-hackers by date

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

pgsql-committers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group