On Wed, Apr 05, 2006 at 12:20:49PM +0200, Martijn van Oosterhout wrote:
> On Wed, Apr 05, 2006 at 06:03:31AM -0400, [EMAIL PROTECTED] wrote:
> > It's no different from a file descriptor on UNIX.
> > Neither UNIX nor Windows promise that a process identifier is valid
> > beyond the life of the process. UNIX avoids it from happening, as it
> > is necessary to avoid races with system calls such as kill(). Windows
> > does not have this problem.
> But consider, why is the process id there? (Amongst other reasons) so
> that users can monitor pg_stat_activity and kill a backend that's out
> of control. The equivalent to this in windows would be to.
> 1. Get HANDLE from the process ID.
> 2. TerminateProcess with that HANDLE.
You missed 1.5. Ensure that HANDLE matches the process you intend. :-)
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.
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?
> 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.
> The race condition in this case involves the user and you can't solve
> that programmatically. The non-reuse of pids is more for
> user-friendlyness than anything else. The Window use of HANDLE doesn't
> solve this problem at all.
Sure you can. But it also shouldn't matter.
> > Sure. Serial. Allocate on process start.
> > Or, back to another topic from months ago - UUID generation... :-)
> Neither of which solve the "I'm a user and want to kill *that* backend"
> problem. Because even on windows you'll have to get the process id,
> convert it to a handle an kill it. Same race condition.
No, and not if PostgreSQL kills the backend for you cleanly, using the
HANDLE, that it owns for the process.
> > 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.
If they do - on the off chance that they do, they should be more
careful than you list above.
That's a kneejerk reaction to a problem that shouldn't occur in the
first place. It's a habit trained by UNIX users.
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...
Cheers,
mark
--
[EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED]
__________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder
|\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ |
| | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada
One ring to rule them all, one ring to find them, one ring to bring them all
and in the darkness bind them...
http://mark.mielke.cc/
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
