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)
pgsql-committers by date:
Соглашаюсь с условиями обработки персональных данных