Re: Latch implementation that wakes on postmaster death on both win32 and Unix

On 26 May 2011 11:22, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
> The Unix-stuff looks good to me at a first glance.

Good.

> There's one reference left to "life sign" in comments. (FWIW, I don't have a
> problem with that terminology myself)

Should have caught that one. Removed.

> Looking at the MSDN docs again, can't you simply include PostmasterHandle in
> the WaitForMultipleObjects() call to have it return when the process dies?
> It should be possible to mix different kind of handles in one call,
> including process handles. Does it not work as advertised?

Uh, I might have done that, had I been aware of PostmasterHandle. I
tried various convoluted ways to make it do what ReadFile() did for
me, before finally biting the bullet and just using ReadFile() in a
separate thread. I've tried adding PostmasterHandle though, and it
works well - it appears to behave exactly the same as my original
implementation.

This simplifies things considerably. Now, on win32, things are
actually simpler than on Unix.

>> You'll see that it takes about a second for the archiver to exit. All
>> processes exit.
>
> Hmm, shouldn't the archiver exit almost instantaneously now that there's no
> polling anymore?

Actually, just one "lagger" process sometimes remains that takes maybe
as long as a second, a bit longer than the others. I assumed that it
was the archiver, but I was probably wrong. I also didn't see that
very consistently.

Attached revision doesn't use any threads or pipes on win32. It's far
neater there. I'm still seeing that "lagger" process (which is an
overstatement) at times, so I guess it is normal. On Windows, there is
no detailed PS output, so I actually don't know what the lagger
process is, and no easy way to determine that immediately occurs to
me.

--
Peter Geoghegan       http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services