Re: Roadmap for a Win32 port

Bruce Momjian wrote:
>
> Let me throw out an idea. I have been mentioning full fork, light
> fork(copy globals only), and threading as possible solutions.
>
> Another idea uses neither threading nor copying. It is the old system
> we used before I removed exec() from our code. We used to pass the
> database name as an argument to an exec'ed postgres binary that
> continued with the database connection.
>
> We removed the exec, then started moving what we could into the
> postmaster so each backend didn't need to do the initialization.
>
> One solution is to return to that for Win32 only, so instead of doing:
>
> initialization()
> want for connection()
> fork backend()
>
> we do for Win32:
>
> want for connection()
> exec backend()
> initialization()

Summarizes pretty much what we discussed Monday on the phone.
Except that the postmaster still has to initialize the shared
memory and other stuff. It's just that the backends and
helper processes need to reinitialize themself (attach).

> It wouldn't be hard to do. We would still do CreateProcess rather than
> CreateThread, but it eliminates the fork/threading issues. We don't
> know the database before the connection arrives, so we don't do a whole
> lot of initialization.

All I see so far is the reading of the postgresql.conf, the
pg_hba.conf and the password files. Nothing fancy and the
postmaster could easily write out a binary content only file
that the backends then read, eliminating the parsing
overhead.

The bad news is that Tom is right. We did a terrible job in
using the new side effect, that the shared memory segment is
at the same address in all forked processes, after removing
the need to reattach.

In detail the XLog code, the FreeSpaceMap code and the
"shared memory" hashtable code now use pointers, located in
shared memory. For the XLog and FreeSpace code this is
understandable, because they where developed under the fork()
only model. But the dynahash code used offsets only until
v7.1!

All three (no claim that that's all) make it impossible to
ever have someone attaching to the shared memory from the
outside. So with these moves we made the shared memory a
"Postmaster and children" only thing. Raises the question,
why we need an IPC key at all any more.

Anyhow, looks as if I can get that fork() vs. fork()+exec()
feature done pretty soon. It'll be controlled by another
Postmaster commandline switch. After cleaning up the mess I
did to get it working quick, I'll provide a patch for
discussion.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck(at)Yahoo(dot)com #