Andrew Dunstan <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> I'm not sure whether there's anything much we can do to prevent such >> problems in future. Maybe it'd be reasonable for pg_regress to do a >> kill -9 on its postmaster child process if it gives up waiting for the >> postmaster to accept connections.
> I'm trying to think how we could harden the buildfarm script to avoid > such situations, although I am so far without any great revelations. > The idea of getting pg_regress to send a signal isn't bad - what if the > PID gets reused, since we know not all systems allocate PIDs in a > cyclical fashion? I think it'd be OK on Unix --- even if the PID has been reused by the time pg_regress tries to kill the child, presumably the reuse would be under a different userid and pg_regress wouldn't have permission to kill it. I am not clear on how to do something equivalent under Windows though. We'd have a HANDLE not a PID coming back from spawn_process, so I suppose there should not be a confusion-of-identity problem, but I don't know what the syscall equivalent to "kill(pid, SIGKILL)" would be. Another problem is that under Unix we will have the exact postmaster PID to try to kill(), because (a) spawn_process uses execl() not system() to invoke the sub-shell and (b) we tell the sub-shell to exec not just call the postmaster. I think under Windows we probably have a HANDLE for an instance of the command line processor, not the postmaster as such, and so I'm worried that killing it would not kill the postmaster anyway. Does Windows have a syscall that would say "kill this process and all its children too"? It may be worth doing the SIGKILL on Unix even if we don't have a solution for Windows, but it'd be nice if to have a solution for the Windows port too. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster