I wrote: > But I'll happily concede the point, and prove it by knocking > up a patch for it over the weekend (unless anyone else > particularly wants to).
Occurs to me I could kill 2 birds with one stone, and also implement another Win32 sticking point, namely the waitpid changes for the Postmaster, by having win32_forkexec do one of the following: a) - when a backend startup is indicated, add a pid/cancel_key struct (Backend) to this new array in shared mem - when any child of the postmaster is started, also add a pid/HANDLE struct to a postmaster local array (or perhaps a dlllist) b) - when any child of the postmaster is started, add a pid/cancel_key/HANDLE/isBackend struct to this new array in shared mem (HANDLE for waiting on to determine child death; isBackend to separate BackendList backends from other children) Choosing a over b: PRO: as we've already been through, keeps the postmaster-only data local to the postmaster, stopping tampering from rouge backends CON: yet more redundancy Given recent conversations, I'm guessing (a), but any comments before going ahead and doing it? Claudio --- Certain disclaimers and policies apply to all email sent from Memetrics. For the full text of these disclaimers and policies see <a href="http://www.memetrics.com/emailpolicy.html">http://www.memetrics.com/em ailpolicy.html</a> ---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match