From: | "Marek Mosiewicz" <marekmosiewicz(at)poczta(dot)onet(dot)pl> |
---|---|
To: | "'PostgreSQL-development'" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Roadmap for a Win32 port |
Date: | 2002-06-18 20:50:16 |
Message-ID: | 000501c21709$c06d5390$9d22153e@neptun |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I know that Apache Group created special library to handle difference
between different platforms (including win32). They had similar problems
porting Apache to Windows. They build very portable threads api (win32,
POSIX, native Linux thread and more) There is also all IPC stuff (mutex,
signals mmap etc.) and many more. This functions work both on unix and
windows and use most effective implementation (e.g. POSIX functions on
Winodws are slow compared to native).
-----Original Message-----
From: pgsql-hackers-owner(at)postgresql(dot)org
[mailto:pgsql-hackers-owner(at)postgresql(dot)org] On Behalf Of Serge Adda
Sent: Tuesday, June 18, 2002 6:43 PM
To: 'Jan Wieck'; 'Dann Corbit'
Cc: 'Bruce Momjian'; 'Peter Eisentraut'; 'PostgreSQL-development'
Subject: Re: [HACKERS] Roadmap for a Win32 port
Hello,
I am new to PostgreSQL, but I am interested in the Win32 port.
I have studied the architecture of other databases like Oracle.
They have had to turn their multi-process model used on Unix into a
fully
multi-threaded one on Win32. I have the feeling that they have had the
same
debate that the one you have.
The CreateProcess() syscall is very costly on Windows. Some improvements
have been done in Windows XP but it is still far more costly than a Unix
fork().
I have been programming with threads on NT for a long time now.
They are quiet robust and efficient. I fear that it is the only
successful
way to port PostgreSQL.
Sorry for this interruption,
Serge
-----Original Message-----
From: Jan Wieck [mailto:JanWieck(at)Yahoo(dot)com]
Sent: Tuesday, June 18, 2002 16:07
To: Dann Corbit
Cc: Bruce Momjian; Peter Eisentraut; PostgreSQL-development
Subject: Re: [HACKERS] Roadmap for a Win32 port
Dann Corbit wrote:
>
> > -----Original Message-----
> > From: Bruce Momjian [mailto:pgman(at)candle(dot)pha(dot)pa(dot)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(at)Yahoo(dot)com #
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo(at)postgresql(dot)org
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
From | Date | Subject | |
---|---|---|---|
Next Message | Dann Corbit | 2002-06-18 20:50:50 | Re: ECPG won't compile anymore |
Previous Message | Tom Lane | 2002-06-18 20:41:57 | Re: ecpg and bison again |