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
Author: Heikki Linnakangas <heikki.linnakan...@iki.fi>
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().
https://www.postgresql.org/message-id/4E046EA5.8070101%40enterprisedb.com
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.
0001-Create-a-new-session-in-postmaster-by-calling-setsid.patch
Description: Binary data
