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

From Jan Wieck
Subject Re: Roadmap for a Win32 port
Date
Msg-id 3D0F3E9E.D12A27BE@Yahoo.com
Whole thread Raw
In response to Re: Roadmap for a Win32 port  ("Dann Corbit" <DCorbit@connx.com>)
Responses Re: Roadmap for a Win32 port  (Greg Copeland <greg@CopelandConsulting.Net>)
List pgsql-hackers
Dann Corbit wrote:
> 
> > -----Original Message-----
> > From: Bruce Momjian [mailto:pgman@candle.pha.pa.us]
> > Sent: Monday, June 17, 2002 6:20 PM
> > To: Dann Corbit
> > Cc: Jan Wieck; Peter Eisentraut; PostgreSQL-development
> > Subject: Re: [HACKERS] Roadmap for a Win32 port
> >
> >
> > Dann Corbit wrote:
> > > > > It will be at least another copy of the postmaster (dot exe).
> > > >
> > > > Yea, I just liked the idea of the postmaster binary
> > somehow reporting
> > > > the postmaster status.  Seems it is in a better position to
> > > > do that than
> > > > a shell script.
> > >
> > > Architectural notion:
> > > The Postmaster is about 100x bigger than it needs to be.
> > >
> > > The Postmaster needs to set up shared memory and launch servers.  It
> > > does not need to know anything about SQL grammar or any of that
> > > rigamarole.
> > >
> > > It could be a 15K executable.
> > >
> > > Why not have an itty-bitty Postmaster that does nothing but
> > a spawn or a
> > > create process to create threaded Postgres instances?
> >
> > Can't.  postmaster/postgres are symlinks to the same file,
> > and we fork()
> > from postmaster to create backends.  All the code has to be in the
> > postmaster so the fork works.
> 
> Is fork() faster than creation of a new process via exec()?  After the
> creation of the shared memory, the information needed to use it could be
> passed to the Postgres servers on the command line.

exec() does NOT create new processes. It loads another executable file
into the existing, calling process. 

fork() duplicates the calling process. In modern unix variants, this is
done in a very efficient way, so that the text segment (program code) is
shared readonly and everything else (data and stack segments) are shared
copy on write. Thus, fork() itself doesn't even cause memory copying.
That happens later when one of the now two processes writes to a memory
page the first time.

Windows does not have these two separate steps. It wants the full blown
expensive "create process and load executable", or the "let's all muck
around with the same handles" modell, called threading. 

> 
> The startup stuff for PostgreSQL is just a few files.  It does not seem
> insurmountable to change it.  But it is none of my business.  If it is a
> major hassle (for reasons which I am not aware) then I see no driving
> reason to change it.

It has to be changed for Windows, it is a major hassle for reasons I
wasn't aware of, and I am half way through ;-)


Jan

-- 

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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: KSQO parameter
Next
From: Tom Lane
Date:
Subject: Re: ECPG won't compile anymore