Re: Stats collection on Windows - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: Stats collection on Windows
Date
Msg-id 6BCB9D8A16AC4241919521715F4D8BCEA35255@algol.sollentuna.se
Whole thread Raw
In response to Stats collection on Windows  ("Peter Brant" <Peter.Brant@wicourts.gov>)
List pgsql-hackers
> >> What happens if process Y goes away between the time you obtain a
> >> handle for it and the time you try to run this
> DuplicateHandle call?
>
> > I can put together some quick test-code for this if you need me to?
>
> Nah, it was just a rhetorical question meant to poke a hole
> in the claim that Windows can avoid race conditions by using HANDLEs.

That's what I thought, which is why I asked first.


> AFAICS, don't-reuse-PIDs-too-quick has exact analogs that
> Windows has to solve by ensuring it doesn't reuse HANDLEs too quick.

Windows doesn't "reuse HANDLEs" in that way. Handles are like file
descriptors.
The kernel structure represnting the process has a *process id*, not a
handle. That is what uniquely identifies the process. (In the kernel
it's often referred to as a "client id").

The process structure will be held as long as anybody has an open handle
to the process. Thus, as long as this happens, the pid *cannot* be
reused. So one way to assure the pid isn't recycled too soon is to keep
the postmasters handle open "long enough" (the postmaster already has a
handle there - it's just the pgstats process that doesn't have one).
RIght now we close the postmaster handle first (win32_removechild at ~
2086 in postmaster.c) and then fire off the message (CleanupBackend at
~2239).

//Magnus


pgsql-hackers by date:

Previous
From: "stephen joseph butler"
Date:
Subject: Re: Stats collection on Windows
Next
From: "Pavel Stehule"
Date:
Subject: Re: commit callback, request