I wrote: >> Not only DNS, but all the various auth libraries would have to be >> contended with. Lots of work there compared to the likely rewards.
> Wait a minute. The entire authentication cycle happens inside > InitPostgres, using the backend's normal signal handlers. So > maybe we are overthinking the problem. What if we simply postpone > ProcessStartupPacket into that same place, and run it under the same > rules as we do for authentication? Or, continuing to look for other answers ... During BackendInitialize we have not yet touched shared memory. This is not incidental but must be so, per its header comment. Therefore it seems like we could have these signal handlers (for SIGTERM or timeout) do _exit(1), thereby resolving the signal unsafety while not provoking a database restart. We don't care whether inside-the-process state is sane, and we shouldn't have changed anything yet in shared memory. This is obviously not 100.00% safe, since maybe something could violate these assumptions, but it seems a lot safer than using proc_exit() from a signal handler. One way to help catch any such assumption-violations is to add an assertion that no on_shmem_exit handlers have been set up yet. If there are none, there should be no expectation of having to clean up shared state. regards, tom lane