Bruce Momjian <br...@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. Or we could wait to see if anybody reports this sort of behavior in a shell that won't be out of support before 9.4 gets out the door. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers