Talkative initdb, elog message levels

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> I'm also somewhat annoyed that these messages show up during initdb
> now. Anyone know why exactly? I couldn't trace it down.

I assume you're talking about this DEBUG stuff:

...
Creating directory /home/postgres/testversion/data/pg_xlog
Creating template1 database in /home/postgres/testversion/data/base/1
DEBUG: starting up
DEBUG: database system was shut down at 2000-11-22 14:38:01
DEBUG: CheckPoint record at (0, 8)
DEBUG: Redo record at (0, 8); Undo record at (0, 8); Shutdown TRUE
DEBUG: NextTransactionId: 514; NextOid: 16384
DEBUG: database system is in production state
Creating global relations in /home/postgres/testversion/data/global
DEBUG: starting up
DEBUG: database system was shut down at 2000-11-22 14:38:09
DEBUG: CheckPoint record at (0, 96)
DEBUG: Redo record at (0, 96); Undo record at (0, 0); Shutdown TRUE
DEBUG: NextTransactionId: 514; NextOid: 17199
DEBUG: database system is in production state
Initializing pg_shadow.
Enabling unlimited row width for system tables.
...

AFAICT, it's always been true that elog(DEBUG) will write to stderr,
and initdb does not redirect the backend's stderr. The change is that
with XLOG enabled, there is now code that will do elog(DEBUG) in the
default path of control during initdb's bootstrap processing.
Specifically, all this chatter is coming out of StartupXLOG() in xlog.c.
Evidently, up to now there were no elog(DEBUG) calls encountered during
a normal bootstrap run.

Not sure whether we should change any code or not. I don't much like
the idea of having initdb send stderr to /dev/null, for example.
Perhaps StartupXLOG could be made a little less chatty, however?

BTW, Vadim, what is the reasoning for your having invented aliases
STOP and LOG for elog levels REALLYFATAL and DEBUG? I think it's
confusing to have more than one name for the same severity level.
If we're going to open up the issue of renaming the elog levels to
something saner, there are a whole bunch of changes to be undertaken,
and these aren't the names I'd choose anyway ...

regards, tom lane