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

From: Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, Paul Guo <pguo(at)pivotal(dot)io>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [Patch] Create a new session in postmaster by calling setsid()
Date: 2018-09-12 19:36:22
Message-ID: 87r2hyo7ya.fsf@news-spur.riddles.org.uk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>>>>> "Tom" == Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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)

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2018-09-12 19:37:09 Re: adding tab completions
Previous Message Nikolay Shaplov 2018-09-12 18:40:49 Re: [PATCH][PROPOSAL] Add enum releation option type