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?


Certain disclaimers and policies apply to all email sent from Memetrics.
For the full text of these disclaimers and policies see 

---------------------------(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

Reply via email to