mlw <markw@mohawksoft.com> writes:
> There is a strategy PostgreSQL could use:
> Put all global variables which need to be duplicated in a single
> place, perhaps a struct, which can be copied into the child
> process. On systems without fork(), the memory can be duplicated or
> passed around using a shared memory block, on a system with fork(),
> nothing extra would need to be done. This could be implemented using
> "standard" APIs, with little or no specialized OS knowledge.
> This represents a lot of reworking of code, but should not affect much
> in the way of operation, but would require a lot of typing and
> testing. It would also force restrictions on module static and global
> variables.
Yeah. The real problem with it in my eyes is that it'd be a continuing
maintenance headache: straightforward programming techniques that work
fine on all the Unix ports would fail (perhaps in nonobvious ways) when
moved to Windows, should you forget to put a variable in the right
place.
A lesser objection is that variables that can currently be "static" in
a single module would become exposed to the world, which again is a
maintenance problem.
> The other alternative, is to profile PostgreSQL running in the cygwin
> environment and try to assess where any bottlenecks are, and if there
> are any spot optimizations which can be applied.
It'd be worth trying to understand cygwin issues in detail before we
sign up to do and support a native Windows port. I understand the
user-friendliness objection to cygwin (though one would think proper
packaging might largely hide cygwin from naive Windows users). What
I don't understand is whether there are any serious performance lossages
from it, and if so whether we could work around them.
regards, tom lane
