Re: [Patch] Create a new session in postmaster by calling setsid()

Paul Guo <pguo@pivotal.io>

From: Paul Guo <pguo@pivotal.io>
To: Michael Paquier <michael@paquier.xyz>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Andrew Gierth <andrew@tao11.riddles.org.uk>, pgsql-hackers@postgresql.org
Date: 2018-09-13T07:27:58Z
Lists: pgsql-hackers
On Thu, Sep 13, 2018 at 8:20 AM, Michael Paquier <michael@paquier.xyz>
wrote:

> On Wed, Sep 12, 2018 at 03:55:00PM -0400, Tom Lane wrote:
> > Although pg_ctl could sneak it in between forking and execing, it seems
> > like it'd be cleaner to have the postmaster proper do it in response to
> > a switch that pg_ctl passes it.  That avoids depending on the fork/exec
> > separation, and makes the functionality available for other postmaster
> > startup mechanisms, and opens the possibility of delaying the detach
> > to the end of startup.
>
> I would be fine with something happening only once the postmaster thinks
> that consistency has been reached and is open for business, though I'd
> still think that this should be controlled by a switch, where the
> default does what we do now.  Feel free to ignore me if I am outvoted ;)
> --
> Michael
>

From the respective of users instead of developers, I think for such
important
service, tty should be dissociated, i.e. postmaster should be daemonized by
default (and even should have default log filename?) or be setsid()-ed at
least.
For concerns from developers, maybe a shell alias, or an internal switch in
pg_ctl,
or env variable guard in postmaster code could address.

I'm not sure the several-years-ago LINUX_OOM_ADJ issue (to resolve that,
silient_mode was removed) still exists or not. I don't have context  about
that, so
I conceded to use setsid() even I prefer the deleted silent_mode code.

Commits

  1. Detach postmaster process from pg_ctl's session at server startup.

  2. Remove silent_mode. You get the same functionality with "pg_ctl -l