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

From Tom Lane
Subject Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.
Date
Msg-id 27265.1300497172@sss.pgh.pa.us
Whole thread Raw
In response to Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.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
argumentson 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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Re: [COMMITTERS] pgsql: Basic Recovery Control functions for use in Hot Standby. Pause,
Next
From: Robert Haas
Date:
Subject: Re: pg_ctl restart - behaviour based on wrong instance