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.