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.
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
