Tom Lane wrote:
>
> mlw <markw@mohawksoft.com> 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?
