Re: Stats collection on Windows

> This is a little bit of a distraction though, as any system
> that requires the user to be able to kill broken backends, is
> only indicative of a broken backend. We're talking about how
> to deal with a broken process, after the process owner
> (PostgreSQL) has forgotten about it.

Don't confuse the postmaster with the statistics system. the postmaster
knows about the backends per handle, but the stats system runs outside
of the postmaster, and can possibly get confused.


> What would be wrong with having a PostgreSQL generated serial
> associated with each backend, that can be used by the backend
> process owner, to map to a HANDLE, which uses
> TerminateProcess() underneath?

It might be a good idea to use the combination pid+internalid. Note taht
we *don't* just want to TerminateProcess(), we need the pid to send
actual signals with. And in this case, that's not even the problem - the
problem is that we're not dropping the process from our list (I think).


> > Presumably users have a little GUI app that displays
> processes on the
> > system with the process ID so they can kill it. If a process ID is
> > quickly reused, they may end up killing the wrong one.
>
> Sure. But the problem here, is that PostgreSQL is broken, so
> they find a need to go to their process listing GUI. And who
> is to say that the GUI doesn't do as I've suggested above?
> Ensure that TerminateProcess() is against the intended
> process? I have no idea if it does - but it could.

Because the GUI is most likely either Task Manager or Process Explorer.
There is no need for a special GUI.


> > > Process identifier should not be used beyond the life of
> the process.
> > > As soon as wait() removes the process on UNIX, the process
> > > identifier is no longer valid, and could be reused. That the
> > > operating system tries to prevent problems by avoiding recycling
> > > isn't necessarily a good reason to exploit this capability.
> > Yeah, but it's very useful as a user. Consider this scenerio:
> > <process 1234 goes AWOL>
> > kill -INT 1234
> > <check if process still there>
> > kill -TERM 1234
> > <process still there, damn it!>
> > kill -9 1234
> > There gone. With no quick PID reuse I can be sure I won't kill the
> > wrong one. This is presumably why recent versions of windows don't
> > reuse pids quickly either... It for *users* not programs.
>
> Users shouldn't need to kill programs.

And normally they don't. But again, this isn't where the problem is. If
your process is stuck and you need to kill it, it most likely will still
be around once you get to killing it. If not, you were trying to kill it
too soon.


> I rarely ever need to kill a process on my Windows box, and
> when I have, the process listing in the GUI hasn't offered me
> a process ID. I click on the item I wish to kill, and I right
> click "End Process". A lot more user friendly, in my opinion.
> And if they happen to fix the race in the background using
> the method I suggest above? All the better...

AFAIK, Task Manager uses the pid to kill the task. Try tracing it. (And
it will happily show you the pid as well - just enable it in the
checkbox. It's the only reasonable way to differ between two processes
off the same exe, for example two different notepad:s...)

//Magnus