Tom Lane wrote: > > mlw <[EMAIL PROTECTED]> writes: > > Without some buy-in from the core team, I'm not sure I am willing to spend my > > time on it. If someone would be willing to fund the 100 or so man-hours > > required to do it, then that would be a different story. > > You are not going to get any buy-in with such ridiculous claims as that. > If the total cost of a native Windows port were O(100 hours), it'd have > been done long since. Add a couple zeroes on the end and I'd start to > believe that you might have some grasp of the problem.
I was basing my estimates on a couple things. Please feel free to correct me where I'm wrong. Dann Corbit mentioned a number of, I think I recall, a couple hundred man-hours for their port. My approach would be to find all the global variables setup by postmaster, not all the globals, mind you. Just the ones initialized by postmaster. Move them to a structure. That structure would be capable of being copied to the child process. In the area where forking the postgres process happens, I would ifdef that area with an "HAS_FORK" The Windows portion would use CreateProcess. The Windows version of postgres would contact the postmaster and get its copy of the globals struct. The code to transfer ownership of sockets, files, and memory would have to be written also. I would only minimally change the back-end code, it would still be built with cygwin tools only directed not to link against the cygwin.dll. (The same goes for the utilities as well.) A thin port layer could then be constructed by either implementing sysv/UNIX replacements, or a more simple API as needed in the code, like your shared memory and semaphore APIs. Does that sound like an unworkable plan? ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
