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