Skip site navigation (1) Skip section navigation (2)

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

From: tgl(at)postgresql(dot)org (Tom Lane)
To: pgsql-committers(at)postgresql(dot)org
Subject: pgsql: Adjust elog.c so that elog(FATAL) exits (including cases where
Date: 2006-11-21 00:49:55
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-committers
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:
        bootstrap.c (r1.225 -> r1.226)
        bgwriter.c (r1.29 -> r1.30)
        postmaster.c (r1.501 -> r1.502)
        postgres.c (r1.516 -> r1.517)
        elog.c (r1.175 -> r1.176)

pgsql-committers by date

Next:From: Tom LaneDate: 2006-11-21 01:23:37
Subject: pgsql: Change the default setting for log_min_error_statement to ERROR.
Previous:From: Bruce MomjianDate: 2006-11-20 22:07:57
Subject: pgsql: Retitle documentation section, "Statement-Based Replication Using

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group