]> granicus.if.org Git - postgresql/commit
Adjust elog.c so that elog(FATAL) exits (including cases where ERROR is
authorTom Lane <tgl@sss.pgh.pa.us>
Tue, 21 Nov 2006 00:49:55 +0000 (00:49 +0000)
committerTom Lane <tgl@sss.pgh.pa.us>
Tue, 21 Nov 2006 00:49:55 +0000 (00:49 +0000)
commite82d9e6283d6ca19d1ea7547e7e9ae8399471e1a
treeb6f413821ac86b98dad1dacc461dd6a70a570696
parent778bb7b60d8b36029f9e874a1b38428115bef0d1
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?
src/backend/bootstrap/bootstrap.c
src/backend/postmaster/bgwriter.c
src/backend/postmaster/postmaster.c
src/backend/tcop/postgres.c
src/backend/utils/error/elog.c