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.