Thread: Interesting failure mode for initdb

Assume a configuration problem that causes standalone backends to fail
without doing anything.  (I happened across this by tweaking global.bki
in such a way that the superuser name entered into pg_shadow was
different from what getpwname returns.  I don't have a real-world
example, but I'm sure there are some.)  Unless the failure is so bad
as to provoke a coredump, the backend will print a FATAL error message
and then exit with exit status 0, because that's what it's supposed to
do under the postmaster.

Unfortunately, given the exit status 0, initdb doesn't notice anything
wrong.  And since initdb carefully stuffs ALL stdout and stderr output
from its standalone-backend calls into /dev/null, the user will never
notice anything wrong either, unless he's attuned enough to realize that
initdb should've taken longer.

I think one part of the fix is to modify elog() so that a FATAL exit
results in exit status 1, not 0, if not IsUnderPostmaster.  But this
will not help the user of initdb, who will still have no clue why
the initdb is failing, even if he turns on debug output from initdb.

I tried modifying initdb along the lines of removing "-o /dev/null"
from PGSQL_OPT, and then writing (eg)

echo "CREATE TRIGGER pg_sync_pg_pwd AFTER INSERT OR UPDATE OR DELETE ON pg_shadow" \    "FOR EACH ROW EXECUTE PROCEDURE
update_pg_pwd()"\    | "$PGPATH"/postgres $PGSQL_OPT template1 2>&1 >/dev/null \    | grep -v ^DEBUG || exit_nicely
 

so that all non-DEBUG messages from the standalone backend would appear
in initdb's output.  However, this does not work because then the ||
tests the exit status of grep, not postgres.  I don't think
(postgres || exit_nicely) | grep

would work either --- the exit will occur in a subprocess.

At the very least we should hack initdb so that --debug removes
"-o /dev/null" from PGSQL_OPT, but can you see any way to provide
filtered stderr output from the backend in the normal mode of operation?
        regards, tom lane

Tom Lane writes:

> I think one part of the fix is to modify elog() so that a FATAL exit
> results in exit status 1, not 0, if not IsUnderPostmaster.

Right.

> At the very least we should hack initdb so that --debug removes
> "-o /dev/null" from PGSQL_OPT, but can you see any way to provide
> filtered stderr output from the backend in the normal mode of operation?

I've removed some of the >/dev/null's and the only undesired output I get
is of this form:

Enabling unlimited row width for system tables.

POSTGRES backend interactive interface
$Revision: 1.208 $ $Date: 2001/02/24 02:04:51 $

backend> backend>
POSTGRES backend interactive interface
$Revision: 1.208 $ $Date: 2001/02/24 02:04:51 $

backend> backend> Creating system views.

POSTGRES backend interactive interface
$Revision: 1.208 $ $Date: 2001/02/24 02:04:51 $

ISTM that the backend shouldn't print a prompt when it's non-interactive.
Then maybe we don't need to filter the output at all.

-- 
Peter Eisentraut      peter_e@gmx.net       http://yi.org/peter-e/

Peter Eisentraut <peter_e@gmx.net> writes:
> I've removed some of the >/dev/null's and the only undesired output I get
> is of this form:

> POSTGRES backend interactive interface
> $Revision: 1.208 $ $Date: 2001/02/24 02:04:51 $

> backend> backend>
> POSTGRES backend interactive interface
> $Revision: 1.208 $ $Date: 2001/02/24 02:04:51 $

That stuff comes out on stdout; all of the interesting stuff is on
stderr.  I don't have a problem with routing stdout to /dev/null.

> ISTM that the backend shouldn't print a prompt when it's non-interactive.

More trouble than it's worth, I think ...
        regards, tom lane

I said:
> That stuff comes out on stdout; all of the interesting stuff is on
> stderr.

Actually, given the -o option all of the interesting stuff will go to
wherever -o says.

At this stage of the release cycle I suppose we must resist the
temptation to define -o '|command' as doing a popen(), but maybe
for 7.2 something could be done with "-o '|grep -v ^DEBUG'" ...
        regards, tom lane