Magnus Hagander <mag...@hagander.net> writes: > On May 10, 2012 4:59 PM, "Tom Lane" <t...@sss.pgh.pa.us> wrote: >> I spent some time staring at the Windows WaitLatchOrSocket code myself. >> The only thing I could find that seemed wrong is that in the event >> array, we list the latch's event before pgwin32_signal_event. The >> Microsoft documentation I looked at says that if more than one event >> is ready, WaitforMultipleObjects reports the first such array member. >> This means that if the latch is already set when control gets here, >> signal handlers will not be serviced.
> Yeah, that does seem wrong. >> That doesn't match what would >> happen on a Unix machine, so it seems like at least a violation of the >> POLA. Hence I think we oughta swap the order of those two array >> elements. (Same issue in PGSemaphoreLock, btw, and I'm suspicious of >> pgwin32_select.) I do not however > Maybe we need a loop that checks for all events? I don't think so. It's already the case that WaitLatch doesn't guarantee that all possible flags are set in its result. In connection with Peter G's observation that we could simplify the API by rechecking PostmasterIsAlive for WL_POSTMASTER_DEATH, I was planning to clarify the API spec as "result bits that are set are guaranteed to reflect reality, but it's not guaranteed that we set every bit that could possibly be set". This should not break any caller since the same result could occur given a slight change in timing anyway; the caller has to be prepared to come back and check for more conditions after it services whatever WaitLatch does report. However, signal service is not a condition the caller is supposed to deal with, so I think we want a guarantee that that happens inside WaitLatch. >> see a way that that would explain the >> pgstat failures, because the stats collector's latch really shouldn't >> ever get set during normal regression test runs. > So could there be something wrong in the other end, meaning the latch > *does* get set? Even if it did, it'd get cleared at the top of the loop, so that the next call ought to handle things. Tis a puzzlement. AFAICS the only condition WaitforMultipleObjects is going to see in these tests is read-ready on the socket; surely it wouldn't fail to notice that? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers