1
0
mirror of https://github.com/postgres/postgres.git synced 2025-06-29 10:41:53 +03:00

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?
This commit is contained in:
Tom Lane
2006-11-21 00:49:55 +00:00
parent 778bb7b60d
commit e82d9e6283
5 changed files with 39 additions and 40 deletions

View File

@ -8,7 +8,7 @@
* Portions Copyright (c) 1994, Regents of the University of California
*
* IDENTIFICATION
* $PostgreSQL: pgsql/src/backend/bootstrap/bootstrap.c,v 1.225 2006/10/04 00:29:49 momjian Exp $
* $PostgreSQL: pgsql/src/backend/bootstrap/bootstrap.c,v 1.226 2006/11/21 00:49:54 tgl Exp $
*
*-------------------------------------------------------------------------
*/
@ -421,15 +421,8 @@ BootstrapMain(int argc, char *argv[])
case BS_XLOG_STARTUP:
bootstrap_signals();
StartupXLOG();
/*
* These next two functions don't consider themselves critical,
* but we'd best PANIC anyway if they fail.
*/
START_CRIT_SECTION();
LoadFreeSpaceMap();
BuildFlatFiles(false);
END_CRIT_SECTION();
proc_exit(0); /* startup done */
case BS_XLOG_BGWRITER: