Hi,
On 2023-02-03 02:50:38 -0500, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > On 2023-02-03 02:24:03 -0500, Tom Lane wrote:
> >> setsid(2) is required since SUSv2, so I'm not sure which systems
> >> are of concern here ... other than Redmond's of course.
>
> > I was thinking of windows, yes.
>
> But given the lack of fork(2), Windows requires a completely
> different solution anyway, no?
Not sure it needs to be that different. I think what we basically want
is:
1) Something vaguely popen() shaped that starts a subprocess, while
being careful about signal handlers, returning the pid of the child
process. Not sure if we want to redirect stdout/stderr or
not. Probably not?
2) A blocking wrapper around 1) that takes care to forward fatal signals
to the subprocess, including in the SIGQUIT case and probably being
interruptible with query cancels etc in the relevant process types.
Thinking about popen() suggests that we have a similar problem with COPY
FROM PROGRAM as we have in pgarch (i.e. not as bad as the startup
process issue, but still not great, due to
procsignal_sigusr1_handler()).
What's worse, the problem exists for untrusted PLs as well, and
obviously we can't ensure that signals are correctly masked there.
This seems to suggest that we ought to install a MyProcPid != getpid()
like defense in all our signal handlers...
Greetings,
Andres Freund