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

Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.
Date: 2011-03-19 01:12:52
Message-ID: 27265.1300497172@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-committerspgsql-hackers
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> As a side note, it's not very obvious why some parts of PostmasterMain
> report problems by doing write_stderr() and exit() while other parts
> use ereport(ERROR).  This check and the nearby checks on WAL level are
> immediately preceded and followed by other checks that use the
> opposite technique.

This question is answered in postmaster.c's header comment:

 * Error Reporting:
 *		Use write_stderr() only for reporting "interactive" errors
 *		(essentially, bogus arguments on the command line).  Once the
 *		postmaster is launched, use ereport().	In particular, don't use
 *		write_stderr() for anything that occurs after pmdaemonize.

Code that is involved in GUC variable processing is in a gray area, though,
since it can be invoked both before and after pmdaemonize.  It might be
a good idea to convert all the calls into ereports and maintain a state
flag in elog.c to determine what to do.

			regards, tom lane

In response to

pgsql-hackers by date

Next:From: Robert HaasDate: 2011-03-19 01:18:13
Subject: Re: pgsql: Document the all-balls IPv6 address.
Previous:From: Tom LaneDate: 2011-03-19 00:52:37
Subject: Re: Re: [COMMITTERS] pgsql: Basic Recovery Control functions for use in Hot Standby. Pause,

pgsql-committers by date

Next:From: Robert HaasDate: 2011-03-19 01:18:13
Subject: Re: pgsql: Document the all-balls IPv6 address.
Previous:From: Tom LaneDate: 2011-03-19 01:05:39
Subject: Re: pgsql: Remove ancient -X options to pg_dump, pg_dumpall, pg_restore.

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