> -----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.

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.

Mon, 17 Jun 2002 18:25:48 -0700
"Dann Corbit" <DCorbit@connx.com>
Re: Roadmap for a Win32 port
Dann Corbit wrote:
> > 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.
> 
> 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.

We used to fork() and exec(), but that was slow.  Now we preload stuff
in the postmaster for each backend.  It is faster.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Mon, 17 Jun 2002 21:27:02 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Roadmap for a Win32 port
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 #

Tue, 18 Jun 2002 10:07:26 -0400
Jan Wieck <JanWieck@Yahoo.com>
Re: Roadmap for a Win32 port
On Tue, 2002-06-18 at 09:07, Jan Wieck wrote:
> Dann Corbit wrote:
> > 
> > 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 ;-)
> 

Well, if you're going to go through the trouble of rewriting postmaster
to be win32 specific, you might as well make it hook into the services
control panel.

If I recall, shared memory is "owned" by a process in Win32 (please
correct as needed...as I've slept since I last looked).  That means that
the postmaster process not only owns the shared memory but needs to make
sure that it's persists as the rest of postgres is expecting.

Please provide more details as to the nature of your Win32 changes.  I'm
certainly curious.  If you've already covered them, just say so...I have
no problem going back to the archives! :)

Greg
18 Jun 2002 10:56:38 -0500
Greg Copeland <greg@CopelandConsulting.Net>
Re: Roadmap for a Win32 port