pgsql: Adjust elog.c so that elog(FATAL) exits (including cases where

Log Message:
-----------
Adjust elog.c so that elog(FATAL) exits (including cases where ERROR is
promoted to FATAL) end in exit(1) not exit(0). Then change the postmaster to
allow exit(1) without a system-wide panic, but not for the startup subprocess
or the bgwriter. There were a couple of places that were using exit(1) to
deliberately force a system-wide panic; adjust these to be exit(2) instead.
This fixes the problem noted back in July that if the startup process exits
with elog(ERROR), the postmaster would think everything is hunky-dory and
proceed to start up. Alternative solutions such as trying to run the entire
startup process as a critical section seem less clean, primarily because of
the fact that a fair amount of startup code is shared by all postmaster
children in the EXEC_BACKEND case. We'd need an ugly special case somewhere
near the head of main.c to make it work if it's the child process's
responsibility to determine what happens; and what's the point when the
postmaster already treats different children differently?

Modified Files:
--------------
pgsql/src/backend/bootstrap:
bootstrap.c (r1.225 -> r1.226)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/bootstrap/bootstrap.c.diff?r1=1.225&r2=1.226)
pgsql/src/backend/postmaster:
bgwriter.c (r1.29 -> r1.30)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/postmaster/bgwriter.c.diff?r1=1.29&r2=1.30)
postmaster.c (r1.501 -> r1.502)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/postmaster/postmaster.c.diff?r1=1.501&r2=1.502)
pgsql/src/backend/tcop:
postgres.c (r1.516 -> r1.517)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/tcop/postgres.c.diff?r1=1.516&r2=1.517)
pgsql/src/backend/utils/error:
elog.c (r1.175 -> r1.176)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/error/elog.c.diff?r1=1.175&r2=1.176)