Re: Global Variables (Was: Re: Discontent with development - Mailing list pgsql-hackers

"Marc G. Fournier" wrote:
> 
> Mark (mlw) ... could you generate a listing of those variables you feel
> would need to be moved to a 'global structure' and post that to the list?
> That would at least give us a starting point, instead of both sides
> guessing at what is/would be involved ...

(1) All the configuration info.
(2) All the globals in postmaster.c
(3) Make sure that memory contexts are initialized correctly.
(4) Exception handling.
(5) Make sure that the statistics and other child processes work too.

In BackendStartup(), rather than "pid = fork();" You should split the routine
at that point, one end will be called for error and successful exec of child
process, another will be called for the child.

On UNIX, it will merely be a slight rearrangement of the code. On Windows it
will represent a different function which will copy the globals from the
parent, and call in. Think of it like this:

Currently it looks something like this:

BackendStartup(port)
{....pid = fork();
if( pid < 0)    // errorelse if(pid )    // Still in Parentelse    // Do child    
}

This would have to change to this:

BackendStartup(port)
{...
pid = StartBackendProcess(port);
if(pid < 0)    // Errorelse if(pid)    // Still in Parentelse    exit(DoBackend()); // Will never happen on Windows.
}

#ifdef WIN32
StartBackendProcess(port)
{HANDLE hprocess= CreateProcess("...../postgres", ....);
(initialize process here)return hprocess;
}
#endif
#ifdef HAS_FORK
StartBackendProcess(port)
{return fork();
}
#endif

In the main code (src/backend/main), you would have to pass a parameter to the
backend to inform it that is being started as a child of the postmaster, and to
call DoBackend() under windows. MPI does this sort of thing.

I see the whole thing as fairly straight forward. Fork is nothing more than a
copy. We should be able to identify what postmaster does prior to the fork of a
backend. The tricks are to handle the shared memory and semaphores, but those
are easy too. We could create a DLL for Postgres which has implicitly shared
data amongst the processes, and make sure that Postmaster updates all the
shared data prior to entering its server loop. That way the backends are only
reading data from a shared resource.

Once the Windows version of PostgreSQL is able to exec the child, I think the
areas where there are things that were missed should be pretty obvious.

It should take a pretty good engineer a few (full time, 40+ hours) weeks. It
should be mostly done the first week, the last two weeks would be chasing bugs
created by variables that were not initialized. This assumes, of course, that
you are using a cygwin build environment without the cygwin or cygipc dlls. If
we were to use MS C/C++ it would take a much longer time, although ultimately
that may be the desired direction.

P.S.
I have unsubscribed from the hackers list, if you wish to contact me, use my
email address directly.