Hello,
Recently I encountered an issue during testing and rootcaused it as the title mentioned.
postmaster children have done this (creating a new session) by calling InitPostmasterChild(),
but postmaster itself does not. This could lead to some issues (e..g signal handling). The test script below is a simple example.
$ cat test.sh
pg_ctl -D ./data -l stop.log stop
sleep 2 -- wait for pg down.
pg_ctl -D ./data -l start.log start
sleep 2 -- wait for pg up.
echo "pg_sleep()-ing"
psql -d postgres -c 'select pg_sleep(1000)' -- press ctrl+c, then you will see postmaster and its children are all gone.
Long ago PG has pmdaemonize() to daemonize postmaster which of course create a new session. That code was removed in the patch below.
commit f7ea6beaf4ca02b8e6dc576255e35a5b86035cb9
Date: Mon Jul 4 14:35:44 2011 +0300
Remove silent_mode. You get the same functionality with "pg_ctl -l
postmaster.log", or nohup.
There was a small issue with LINUX_OOM_ADJ and silent_mode, namely that with
silent_mode the postmaster process incorrectly used the OOM settings meant
for backend processes. We certainly could've fixed that directly, but since
silent_mode was redundant anyway, we might as well just remove it.
Here is the related discussion about the patch. It seems that is related to oom score setting in fork_process().
Personally I still like pg being a daemon, but probably I do not know some real cases which do not like daemon. If we do not go back to pgdaemonize() with further fix of fork_process() (assume I understand correctly) we could simply call setsid() in postmaster code to fix the issue above. I added a simple a patch as attached.
Thanks.