Re: Roadmap for a Win32 port - Mailing list pgsql-hackers

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
theshared   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
fancyand 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
segmentis   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
developedunder 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
fromthe   outside. So with these moves we  made  the  shared  memory  a   "Postmaster  and  children" only thing.
Raisesthe 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
byanother   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@Yahoo.com #