mlw <markw@mohawksoft.com> writes:
> I did, and yes I was confused. Sorry. Your posix implementation assumes that
> only a single process will have access to the semaphore list for deletion is
> this correct? I guess I need to know how much access the child processes need
> to have to the internal control structures, none? Some? All?
None. The postmaster creates the semas, and the postmaster deletes 'em.
The children only use them via the PGSemaphore structs they find in
shared memory. (The SysV implementation assumes that too btw.)
> With no fork(), information that would normally be copied on fork() is not
> copied. Therefore, we need to know what that information is and how to
> propagate it to the child process (under windows)
This will be a royal mess. Three or four years ago, when PG actually
did fork/exec to start a backend, we were careful to arrange to pass
everything the backend needed to know as command-line parameters (or
else keep it in shared memory). We have been busily breaking that
separation ever since we went over to fork-no-exec, however. In the
current scheme of things there is no chance whatever of a backend
working unless it inherits the global/static variables of the
postmaster.
And no, I don't want to undo those changes. Especially not if the
only reason for it is to not have to use Cygwin on Windows. Most
of these changes made the startup code substantially simpler,
faster, and more reliable.
regards, tom lane
