From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> |
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:55:00 |
Message-ID: | 15239.1536782100@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> writes:
> "Tom" == Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> Tom> Hmph. Can't we just ignore that error?
> If you ignore the error from setsid(), then you're still a process group
> leader (as you would be after running setsid()), but you're still
> attached to whatever controlling terminal (if any) you were previously
> attached to.
Oh, got it. So actually, the setsid has to be done by what is/will be
the postmaster process.
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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2018-09-12 20:03:57 | Re: PATCH: Update snowball stemmers |
Previous Message | Andrew Gierth | 2018-09-12 19:46:39 | Re: [Patch] Create a new session in postmaster by calling setsid() |