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 recoverywant to accomplish (maybe there is a different way to fix
it on win32)?
Kill a process along with all it's subprocesses?
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.
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
