>>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:
Tom> BTW, just thinking outside the box a bit --- perhaps the ideal
Tom> behavior to address Michael's use-case would be to have the
Tom> postmaster itself do setsid(), but not until it reaches the state
Tom> of being ready to accept client connections.
Tom> We'd likely need a switch to control that. If memory serves, there
Tom> used to be such a switch, but we got rid of the postmaster's
Tom> setsid call and the switch too. We probably should dig in the
Tom> archives and review the reasoning about that.
The old silent_mode switch?
The tricky part about doing setsid() is this: you're not allowed to do
it if you're already a process group leader. silent_mode worked by
having postmaster do another fork, exit in the parent, and do setsid()
in the child.
If postmaster is launched from pg_ctl, then it won't be a group leader
unless pg_ctl made it one. But when it's run from the shell, it will be
if the shell does job control (the initial command of each shell job is
the group leader); if it's run from a service management process, then
it'll depend on what that process does.
--
Andrew (irc:RhodiumToad)
