Thread: How does EXEC_BACKEND process signals?

In testing the new autovac facility, I noticed this log in the
EXEC_BACKEND (on Linux) scenario (I pressed Ctrl-C only once):

DEBUG:  postmaster received signal 2
LOG:  received fast shutdown request
LOG:  aborting any active transactions
FATAL:  terminating connection due to administrator command
FATAL:  terminating connection due to administrator command
FATAL:  terminating connection due to administrator command
FATAL:  terminating connection due to administrator command
FATAL:  terminating connection due to administrator command
FATAL:  terminating connection due to administrator command
FATAL:  terminating connection due to administrator command
DEBUG:  drop cascades to table fktable
DEBUG:  drop auto-cascades to type fktable
DEBUG:  drop cascades to table pktable
DEBUG:  drop auto-cascades to type pktable
DEBUG:  drop auto-cascades to constraint pktable_pkey on table pktable
DEBUG:  drop auto-cascades to index pktable_pkey
DEBUG:  server process (PID 21893) exited with exit code 1
DEBUG:  server process (PID 21895) exited with exit code 1
DEBUG:  server process (PID 21899) exited with exit code 1
DEBUG:  server process (PID 21900) exited with exit code 1
DEBUG:  server process (PID 21902) exited with exit code 1
DEBUG:  server process (PID 21904) exited with exit code 1
DEBUG:  server process (PID 21906) exited with exit code 1
LOG:  shutting down
LOG:  autovacuum launcher shutting down
DEBUG:  forked new backend, pid=21907 socket=6
LOG:  database system is shut down
LOG:  background writer process (PID 21220) exited with exit code 0
LOG:  terminating any other active server processes
DEBUG:  sending SIGQUIT to process 21907
DEBUG:  server process (PID 21907) exited with exit code 1
LOG:  all server processes terminated; reinitializing
LOG:  database system was shut down at 2007-01-26 20:21:10 CLST
LOG:  checkpoint record is at 0/4293338
LOG:  redo record is at 0/4293338; undo record is at 0/0; shutdown TRUE
LOG:  next transaction ID: 0/17395; next OID: 60723
LOG:  next MultiXactId: 1; next MultiXactOffset: 0
LOG:  database system is ready
DEBUG:  transaction ID wrap limit is 2147484176, limited by database "postgres"
LOG:  shutting down
DEBUG:  recycled transaction log file "000000010000000000000002"
DEBUG:  recycled transaction log file "000000010000000000000003"
LOG:  database system is shut down

The strange thing is that we're seeing a "forked a new backend" line
_after_ the shutdown signal was received.  I don't think this is related
to my local changes, because I've been careful with that, but one never
knows.

I wonder if this could cause more than just a curiosity.  The backend
was evidently shut down promptly.

I'll post the autovac patch right away.

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

Alvaro Herrera <alvherre@commandprompt.com> writes:
> The strange thing is that we're seeing a "forked a new backend" line
> _after_ the shutdown signal was received.

No, nothing surprising about that if you had clients that might try to
connect at that time.  The "canAcceptConnections" test doesn't occur
till after the fork, mainly because we don't want the postmaster risking
blocking itself trying to send error messages to clients.
        regards, tom lane