On Tue, Apr 04, 2006 at 11:02:11PM -0400, Tom Lane wrote:
> "Peter Brant" <Peter.Brant@wicourts.gov> writes:
> > I think I've found the cause (or one of the causes) why stats
> > collection is unreliable on Windows and I'm wondering about the best way
> > to go about fixing it.
> > The problem is that process IDs on Windows seem to be assigned without
> > much rhyme or reason and it seems to happen relatively frequently that a
> > new process will be assigned the same process ID as a process which
> > recently died. If this happens before the backend has been expired out
> > of pgstat.c's pgStatBeDead hash, the backend will be missed.
> That's an interesting theory, but do you have any actual evidence for it?
> The evidence I've seen says that our big problem on Windows is the stats
> collector process just quitting due to unexplained piperead() failures.
> (I mean, I'd love to blame Microsoft for everything, but even the
> Redmond crowd should be able to figure out that recycling process IDs
> instantly would be a stupid idea...)
Why? :-)
They use HANDLE. The process ID isn't nearly as useful as it is on UNIX.
I haven't looked at that stuff in a long time, but process "ID" on Windows
may be a compatibility method.
Process "ID" isn't necessarily a good way of identifying tasks,
precisely because they may be reused. Using a serial allocated at
process start might make more sense. Relying on it not being reused,
is not dissimilar to the old malloc() "tricks" of assuming that
malloc() will not return something recently free()d. It's bad.
Cheers,
mark
--
mark@mielke.cc / markm@ncf.ca / markm@nortel.com __________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | 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
bindthem...
http://mark.mielke.cc/