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
-
Detach postmaster process from pg_ctl's session at server startup.
- bb24439cefea 12.0 landed
-
Remove silent_mode. You get the same functionality with "pg_ctl -l
- f7ea6beaf4ca 9.2.0 cited