Re: Ctrl+C from sh can shut down daemonized PostgreSQL cluster
От | Robert Haas |
---|---|
Тема | Re: Ctrl+C from sh can shut down daemonized PostgreSQL cluster |
Дата | |
Msg-id | CA+TgmoZ2T_DmixOuh_XVoLHxQW84-eGJVta9PQuecqOqe4mXNQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Ctrl+C from sh can shut down daemonized PostgreSQL cluster (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Ctrl+C from sh can shut down daemonized PostgreSQL cluster
(Tom Lane <tgl@sss.pgh.pa.us>)
|
Список | pgsql-hackers |
On Mon, Feb 17, 2014 at 8:26 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Bruce Momjian <bruce@momjian.us> writes: >> It certainly might be --- I have no idea. What surprised me is that we >> are relying solely on system() to block signals to pg_ctl-spawned >> servers. The question is whether that is sufficient and whether we >> should be doing more. I don't think we have to make adjustments just >> for Solaris 9. > > We aren't relying on system(); it does no such thing, according to the > POSIX spec. If it did, pg_ctl would be unable to print any errors to the > terminal, because dissociating from the foreground process group generally > also disables your ability to print on the terminal. > > I poked around in the POSIX spec a bit, and if I'm reading it correctly, > the only thing that typically results in the postmaster becoming > dissociated from the terminal is use of "&" to launch it. In a shell > with job control, that should result in the process being put into a > "background" process group that won't receive terminal signals nor be > permitted to do I/O to it. This is distinct from dissociating altogether > because you can use "fg" to return the process to foreground; if we did a > setsid() we'd lose that option, if I'm reading the standards correctly. > So I'm loath to see the postmaster doing setsid() for itself. > > POSIX also mandates that interactive shells have job control enabled by > default. > > However ... the "&" isn't issued in the user's interactive shell. It's > seen by the shell launched by pg_ctl's system() call. So it appears to > be standards-conforming if that shell does nothing to move the launched > postmaster into the background. > > The POSIX spec describes a shell switch -m that forces subprocesses > to be launched in their own process groups. So maybe what we ought > to do is teach pg_ctl to do something like > > system("set -m; postgres ..."); > > Dunno if this is really portable, though it ought to be. > > Alternatively, we could do what the comments in pg_ctl have long thought > desirable, namely get rid of use of system() in favor of fork()/exec(). > With that, pg_ctl could do a setsid() inside the child process. I like this last approach. It seems to me that the problem with system() is that it's relying on the user's shell to have sane behavior. And while that obviously will work fine in a whole lot of cases, I don't see why we should rely on it. I don't think "your shell must support -m with POSIX-like semantics" is really a requirement we want to impose on PostgreSQL users. The shell can't make any system calls that we don't have access to ourselves, and setsid() seems like the right one to use. Maybe it's begging for trouble to change anything here at all, but I think if we are going to make a change it ought to be in the direction of making us less dependent on the vagaries of the user's shell, not more. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: