aboutsummaryrefslogtreecommitdiff
path: root/src/backend/commands/variable.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2006-11-21 00:49:55 +0000
committerTom Lane <tgl@sss.pgh.pa.us>2006-11-21 00:49:55 +0000
commite82d9e6283d6ca19d1ea7547e7e9ae8399471e1a (patch)
treeb6f413821ac86b98dad1dacc461dd6a70a570696 /src/backend/commands/variable.c
parent778bb7b60d8b36029f9e874a1b38428115bef0d1 (diff)
downloadpostgresql-e82d9e6283d6ca19d1ea7547e7e9ae8399471e1a.tar.gz
postgresql-e82d9e6283d6ca19d1ea7547e7e9ae8399471e1a.zip
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?
Diffstat (limited to 'src/backend/commands/variable.c')
0 files changed, 0 insertions, 0 deletions