> > I haven't really been folliowing this thread. What exactly
> is it you
> > want to accomplish (maybe there is a different way to fix
> it on win32)?
> > Kill a process along with all it's subprocesses?
>
> Right. The problem (as seen on Unix) is that if the recovery
> subprocess is waiting for a recovery_command script to
> complete, it doesn't react to SIGQUIT (because system()
> ignores SIGQUIT) and the script doesn't react either (because
> it never gets the signal at all). We'd like "pg_ctl stop -m
> immediate" to abort the script and then have the recovery
> process fail, allowing restart later. More generally, it
> seems like any time a backend is executing system(), the
> called script ought to be subject to SIGINT or SIGQUIT
> signals sent to the backend by the postmaster.
Hm. ok.
Well, first of all, the generic case will never really wrok - because we
send our own kind of signals, and a script (batchfile executing under
cmd.exe) or anythin non-postgresql-backedn will never respond to that
anwyay.
However, for this specific case we might be able to do something. pg_ctl
creates a job object that it assigns the postmaster to when it's started
if that works. (Won't work if pg_ctl itself is running inside a job
object, but normally it won't be doing that). That means that we could
have pg_ctl look up this job object and execute TerminateJobObject() on
it. That will kill all processes inside the job object (includnig
backends, but if we run it from pg_ctl *after* postmaster has shut down,
there should be none of those left).
(This will work for the generic processes as well, but it will *only*
work for the pg_ctl-stops-theprocess scenario, it can't be done from
inside the postmaster)
It's not entirely pretty (to say the least), but might be worthwhile
looking at?
//Magnus