Thread

Path to PostgreSQL portabiliy

mlw <markw@mohawksoft.com> — 2002-05-08T12:35:20Z

Do we want a Win32 native version of PostgreSQL?

The only reasons *not* to use Cygwin is licensing, installation hassles, and
maybe stability or performance. Therefore, there is no strong technical reason
to defend its removal, only a philosophical one.

The debates on licensing on this list go on for weeks and people feel
passionately about the subject. It seems odd that no one speaks out about the
GNU requirement of cygwin.

If there is a desire to create a PostgreSQL that is "fork" free, then we should
do it now. If now strong desire exists, then we should make an entry in the FAQ
and move on.

If we want to be "portable" (and this should help us with a threading model
later on) we need to cleanup all of the global variables.

PostgreSQL's postmaster should not touch any global variables that are defined
outside something like a pg_global structure and should not touch any static
variables at all. If postmaster initializes a variable that will get cloned on
a fork(), conceptually it is a shared global variable and belongs in
pg_globals. Going all the way and replacing all globals and statics with a
struct should allow threading with TLS. (Thread Local Storage)

Port lib. Regardless where it comes from, the porting code should be a self
contained library, not a list of objects. On Windows, a .DLL can do some things
easier than an application. Also, having a library allows more flexibility as
to how a port is designed.

We should spec out our port interface. This includes file, semaphores, shared
memory, signals/events, process control, IPC, system resources, etc. This will
grow as we re-port to other environments like Windows.

any comments?

Re: Path to PostgreSQL portabiliy

Tom Lane <tgl@sss.pgh.pa.us> — 2002-05-08T14:03:43Z

mlw <markw@mohawksoft.com> writes:
> Port lib. Regardless where it comes from, the porting code should be a
> self contained library, not a list of objects. On Windows, a .DLL can
> do some things easier than an application. Also, having a library
> allows more flexibility as to how a port is designed.

That may be necessary on Windoze, but on any other platform breaking out
an essential part of the backend as a library strikes me as a dead loss.
You create extra risk of installation mistakes, can't-find-library
startup failures, version mismatch problems, etc, etc --- for zero gain
that I can see.

For comparison you may want to observe the opinion expressed some time
ago by Peter E. that we should fold plpgsql and the other PL's into
the backend, instead of having them as dynamic-linked libraries.

			regards, tom lane

Re: Path to PostgreSQL portabiliy

mlw <markw@mohawksoft.com> — 2002-05-08T14:16:16Z

Tom Lane wrote:
> 
> mlw <markw@mohawksoft.com> writes:
> > Port lib. Regardless where it comes from, the porting code should be a
> > self contained library, not a list of objects. On Windows, a .DLL can
> > do some things easier than an application. Also, having a library
> > allows more flexibility as to how a port is designed.
> 
> That may be necessary on Windoze, but on any other platform breaking out
> an essential part of the backend as a library strikes me as a dead loss.
> You create extra risk of installation mistakes, can't-find-library
> startup failures, version mismatch problems, etc, etc --- for zero gain
> that I can see.

It does not need, and probably should not be by default, a shared library under
UNIX. A static library is fine. The issue is whether or not it makes sense to
try and design all porting layers the same, or allow the port engineer the
flexibility to create what they need the way they need to do it. 

A side note:
The "Windoze" comment says a lot Tom. Believe me, I am currently no fan of
Windows, but there is something to be said about doing a good job supporting
such a popular platform, regardless of our personal opinions. When I was
working at DMN, I had to make sure we could find country music and Brittany
Spears. Distasteful, but certainly something that needed to be done.

IMHO, I think a great PostgreSQL implementation for Win32 is a nail in the
coffin for Windows. If we give them a great database, which runs well under
Windows, for free, MSSQL will now have a serious competitor for the medium to
small marketplace.

Once MSSQL has viable cross-platform competition in this space, one less
requirement for Windows will exist. Right now, if you implement on Windows, you
are most likely going to use MSSQL and be stuck there. With a good Win32
PostgreSQL, an engineer can implement on PostgreSQL for Windows, and easily
move it to a "real" environment for stability. 

I see it as an important step.

Path to PostgreSQL portabiliy

Lee Kindness <lkindness@csl.co.uk> — 2002-05-08T15:36:15Z

mlw writes:
 > [ snip ]
 > Port lib. Regardless where it comes from, the porting code should be a self
 > contained library, not a list of objects. On Windows, a .DLL can do some things
 > easier than an application. Also, having a library allows more flexibility as
 > to how a port is designed.
 > 
 > We should spec out our port interface. This includes file, semaphores, shared
 > memory, signals/events, process control, IPC, system resources, etc. This will
 > grow as we re-port to other environments like Windows.

In other words ignore the POSIX capabilities/features of the largely
compatible Unix systems and invent a layer over them to aid porting to
more POSIXly challenged systems (i.e. Windows)...

Seems like the wrong way of doing things - change the majority to aid
the minority! Doesn't the current method of relying on POSIX
compatability layers on Windows make more sense?

Even if such a 'port library' was the way forward, it should be just
using an existing one, i.e. Apache [A]PR. No use replicating all the
effort!

Looking into APR got me back to thinking about a PostgreSQL and mmap -
what's the stance on it? Useable? In the archives someone was looking
into mmap use for WAL, but this hasn't reappeared for 7.3... I'm
thinking about using mmap for COPY FROM...

Lee.

Re: Path to PostgreSQL portabiliy

Thomas Lockhart <lockhart@fourpalms.org> — 2002-05-08T15:37:02Z

> The debates on licensing on this list go on for weeks and people feel
> passionately about the subject. It seems odd that no one speaks out about the
> GNU requirement of cygwin.

We respect the licensing requirements for that product. And certainly
the licensing requirement for cygwin are no less onerous than for other
products installed on a Windoze platform, or for Windoze itself.

My impression on the licensing requirement is that there is an
inconvenience factor in installing cygwin separately, and a cost factor
in trying to deliver an integrated build.

But I'm actually not certain about *any* onerous requirements for
cygwin, now that I look at it. 

<disclaimer>
If we've already covered this, just remind me what Truth is, no need to
go over old territory.
</disclaimer>

Here are some points and questions:

1) cygwin is licensed under GPL. So is GNU/Linux, which provides the
same APIs as cygwin does. Linux does not pollute application licenses,
presumably because Linux itself is not *required* to run the
application; it could be run on another system just as well. That is
true for PostgreSQL's relationship to cygwin on Windows, right? Or has
GNU managed to carefully sort out all GPL vs LGPL issues for
applications and libraries to solve it that way?

2) If (1) does not exempt the PostgreSQL app from GPL polution, then why
not distribute PostgreSQL on Windows using a GPL license? It would be a
license fork, but there is no expectation that the GPL licensed code
would be anything other than a strict copy of the BSD code. And the
latter does not preclude anyone from taking the code and distributing it
under another license, as long as the BSD license is distributed also.
There is no problem distributing the PostgreSQL sources with the cygwin
package, so the requirements for the cygwin license can be fully met. I
think that this would be supported by the rest of the community, as long
as it was not an excuse to discuss GPL vs BSD for the main code base.

3) If (2) is the case, then development could continue under the BSD
license, since developers could use the BSD-original code for their
development work. So there is no risk of "backflow polution".

Thoughts (specific to PostgreSQL on cygwin/windoze, which is not a
happening thing at the moment)?

                   - Thomas

Re: Path to PostgreSQL portabiliy

Joel Burton <joel@joelburton.com> — 2002-05-08T15:37:32Z

> -----Original Message-----
> From: pgsql-hackers-owner@postgresql.org
> [mailto:pgsql-hackers-owner@postgresql.org]On Behalf Of mlw
> Sent: Wednesday, May 08, 2002 10:16 AM
> To: Tom Lane
> Cc: PostgreSQL-development; Jan Wieck; Marc G. Fournier; Dann Corbit
> Subject: Re: [HACKERS] Path to PostgreSQL portabiliy
>
> IMHO, I think a great PostgreSQL implementation for Win32 is a nail in the
> coffin for Windows. If we give them a great database, which runs
> well under
> Windows, for free, MSSQL will now have a serious competitor for
> the medium to
> small marketplace.
>
> Once MSSQL has viable cross-platform competition in this space, one less
> requirement for Windows will exist. Right now, if you implement
> on Windows, you
> are most likely going to use MSSQL and be stuck there. With a good Win32
> PostgreSQL, an engineer can implement on PostgreSQL for Windows,
> and easily
> move it to a "real" environment for stability.
>
> I see it as an important step.

... and for IT staff who do their play-work on the Windows laptops, and to
help compete against MySQL, which has a strong, out-of-the-box Windows
binary, and for people who think it's easier to install and play with things
on Windows first, and ...

It seems like there are lot of open paths discussions, though:

. make cygwin perform better (does it perform badly? is it unstable?)

. make cygwin easier to install

. make windows native (req's semaphore, fork, some shell utils, etc.)

I've installed PG+Cygwin on a few dozen machines, but always to let people
play before the real *nix install. Can anyone speak to _really_ using PG +
Cygwin?

Joel BURTON | joel@joelburton.com | joelburton.com | aim: wjoelburton
Knowledge Management & Technology Consultant

Re: Path to PostgreSQL portabiliy

mlw <markw@mohawksoft.com> — 2002-05-08T15:46:39Z

Joel Burton wrote:
> ... and for IT staff who do their play-work on the Windows laptops, and to
> help compete against MySQL, which has a strong, out-of-the-box Windows
> binary, and for people who think it's easier to install and play with things
> on Windows first, and ...
> 
> It seems like there are lot of open paths discussions, though:
> 
> . make cygwin perform better (does it perform badly? is it unstable?)

I don't know if a native Win32 binary will perform better, I do know that Linux
running PostgreSQL performs better than Windows running cygwin and PostgreSQL
on the same machine. The extent of what that means is unclear.

> 
> . make cygwin easier to install

Or just have a stripped down cygwin runtime.

> 
> . make windows native (req's semaphore, fork, some shell utils, etc.)

Hence this whole conversation.

> 
> I've installed PG+Cygwin on a few dozen machines, but always to let people
> play before the real *nix install. Can anyone speak to _really_ using PG +
> Cygwin?

As I think of it, I don't think a cygwin PostgreSQL will *ever* be taken
seriously by the Windows crowd, just as a Wine/CorelDraw wasn't taken seriously
by the Linux crowd.

If we want to support Windows, we should support Windows. Cygwin will not be
accepted by any serious IT team.

Re: Path to PostgreSQL portabiliy

mlw <markw@mohawksoft.com> — 2002-05-08T15:53:30Z

Lee Kindness wrote:
> 
> mlw writes:
>  > [ snip ]
>  > Port lib. Regardless where it comes from, the porting code should be a self
>  > contained library, not a list of objects. On Windows, a .DLL can do some things
>  > easier than an application. Also, having a library allows more flexibility as
>  > to how a port is designed.
>  >
>  > We should spec out our port interface. This includes file, semaphores, shared
>  > memory, signals/events, process control, IPC, system resources, etc. This will
>  > grow as we re-port to other environments like Windows.
> 
> In other words ignore the POSIX capabilities/features of the largely
> compatible Unix systems and invent a layer over them to aid porting to
> more POSIXly challenged systems (i.e. Windows)...
> 
> Seems like the wrong way of doing things - change the majority to aid
> the minority! Doesn't the current method of relying on POSIX
> compatability layers on Windows make more sense?

Depends, do you want the Windows version to actually be used? I have been
writing software for over 20 years now, and sometimes you just have to hold
your nose. It would be nice if we could code what we want, the way we want, in
the language we want, on the platforms we want.

Windows represents a HUGE user base, it also represents a platform for which a
real good native PostgreSQL should do well. There are, to my knowledge, no good
and free databases available for Windows. 

PostgreSQL on Windows could be very cool as a serious poster child for why
open-source is the way to go.

> 
> Even if such a 'port library' was the way forward, it should be just
> using an existing one, i.e. Apache [A]PR. No use replicating all the
> effort!

Absolutely, I think Apache's APR is pretty good.

Re: Path to PostgreSQL portabiliy

Joel Burton <joel@joelburton.com> — 2002-05-08T15:55:36Z

> -----Original Message-----
> From: markw@snoopy.mohawksoft.com [mailto:markw@snoopy.mohawksoft.com]On
> Behalf Of mlw
> Sent: Wednesday, May 08, 2002 11:47 AM
> To: Joel Burton
> Cc: Tom Lane; PostgreSQL-development; Jan Wieck; Marc G. Fournier; Dann
> Corbit
> Subject: Re: [HACKERS] Path to PostgreSQL portabiliy
>
>
> As I think of it, I don't think a cygwin PostgreSQL will *ever* be taken
> seriously by the Windows crowd, just as a Wine/CorelDraw wasn't
> taken seriously
> by the Linux crowd.
>
> If we want to support Windows, we should support Windows. Cygwin
> will not be
> accepted by any serious IT team.

Well, I think it's a bit different than Wine, a _huge_ binary trying to
emulate every call of an operating system (and making things more than a bit
slower).

If there is a stripped down, out-of-the-box install that includes cygwin, do
you think that will turn people off? It would be essentially invisible.

There was a native PG (7.0.3, IIRC) floating around on the web, so _someone_
has done this before.

- J.

Joel BURTON | joel@joelburton.com | joelburton.com | aim: wjoelburton
Knowledge Management & Technology Consultant

Re: Path to PostgreSQL portabiliy

Tom Lane <tgl@sss.pgh.pa.us> — 2002-05-08T15:57:11Z

Thomas Lockhart <lockhart@fourpalms.org> writes:
> 2) If (1) does not exempt the PostgreSQL app from GPL polution, then why
> not distribute PostgreSQL on Windows using a GPL license?

Given the cygwin licensing terms stated at
	http://cygwin.com/licensing.html
it appears to me that we need not open that can of worms (and I'd much
rather not muddy the licensing waters that way, regardless of any
arguments about whether it would hurt or not...)

As near as I can tell, we *could* develop a self-contained installation
package for PG+cygwin without any licensing problem.  So that set of
problems could be solved with a reasonable amount of work.  I'm still
unclear on whether there are serious technical problems (performance,
stability) with using cygwin.

(Actually, even if there are performance or stability problems, an
easily-installable package would still address the needs of people who
want to "try it out" or "get their feet wet".  And maybe that's all we
need to do.  We always have said that we recommend a Unix platform for
production-grade PG installations, and IMNSHO that recommendation would
not change one iota if there were a native rather than cygwin-based
Windows port.  So I'm unconvinced that we have a problem to solve
anyway...)

			regards, tom lane

Re: Path to PostgreSQL portabiliy

mlw <markw@mohawksoft.com> — 2002-05-08T15:58:34Z

Joel Burton wrote:
> 
> > -----Original Message-----
> > From: markw@snoopy.mohawksoft.com [mailto:markw@snoopy.mohawksoft.com]On
> > Behalf Of mlw
> > Sent: Wednesday, May 08, 2002 11:47 AM
> > To: Joel Burton
> > Cc: Tom Lane; PostgreSQL-development; Jan Wieck; Marc G. Fournier; Dann
> > Corbit
> > Subject: Re: [HACKERS] Path to PostgreSQL portabiliy
> >
> >
> > As I think of it, I don't think a cygwin PostgreSQL will *ever* be taken
> > seriously by the Windows crowd, just as a Wine/CorelDraw wasn't
> > taken seriously
> > by the Linux crowd.
> >
> > If we want to support Windows, we should support Windows. Cygwin
> > will not be
> > accepted by any serious IT team.
> 
> Well, I think it's a bit different than Wine, a _huge_ binary trying to
> emulate every call of an operating system (and making things more than a bit
> slower).
> 
> If there is a stripped down, out-of-the-box install that includes cygwin, do
> you think that will turn people off? It would be essentially invisible.

I was thinking about this earlier, one problem with cygwin is it doesn't act
like a Windows program, it requires its own file layout.

Cygwin's purpose in life to to allow basically UNIX centric people to be
comfortable on Windows. It, by no means, is anything that a Windows centric
person wants to deal with, or would deal with if there were an alternative.

Re: Path to PostgreSQL portabiliy

Thomas Lockhart <lockhart@fourpalms.org> — 2002-05-08T16:10:44Z

...
> As near as I can tell, we *could* develop a self-contained installation
> package for PG+cygwin without any licensing problem.

Right. That was my opinion also. But istm that however the discussion
settles out, there is a path to success.

                    - Thomas

Re: Path to PostgreSQL portabiliy

mlw <markw@mohawksoft.com> — 2002-05-08T16:29:07Z

Thomas Lockhart wrote:
> 
> ...
> > As near as I can tell, we *could* develop a self-contained installation
> > package for PG+cygwin without any licensing problem.
> 
> Right. That was my opinion also. But istm that however the discussion
> settles out, there is a path to success.

These last couple days have really started me thinking about Windows again. I
developed Windows software for over a decade, geez much longer than that, I
wrote my first Windows program using the Windows 1.03 SDK. (I am in a 12 step
program now, but you guys are causing a relapse!)

Listen, here is purely my opinion on the matter, I am speaking from my
experience as a Windows user, developer, and author (Tricks of the Windows 3.1
Masters).

It is useless to spend serious time on a cygwin version. Yea, it is cool and
all, but it won't be used. From the eyes of a Windows user cygwin is a hack and
a mess. An IT guy that only knows Windows will never use it, and if presented
with a program that forces a UNIX like directory tree on their hard drive and
UNIX like tools to manage it, they will delete the program and curse the time
spent installing it.

Performance may also be an issue, I don't know for sure, but it is suspected.
The cygwin fork troubles me as well. It may work, but I would not call it a
"production" technique, how about you? Would you bet your business on cygwin
and a hacked fork()?

No matter what steps you take, cygwin will not be seen by Windows users as
anything but a sloppy/messy/horrible hack. It is a fact of life. You are
welcome to disagree, but I assure you it is true.

From a usefulness perspective, a cygwin version of PostgreSQL will be nothing
more than a proof of concept, a test bed, or a demo. It will never be used as a
serious database. How much work does that warrant?

Re: Path to PostgreSQL portabiliy

Marc G. Fournier <scrappy@hub.org> — 2002-05-08T16:41:18Z

On Wed, 8 May 2002, Tom Lane wrote:

> Thomas Lockhart <lockhart@fourpalms.org> writes:
> > 2) If (1) does not exempt the PostgreSQL app from GPL polution, then why
> > not distribute PostgreSQL on Windows using a GPL license?
>
> Given the cygwin licensing terms stated at
> 	http://cygwin.com/licensing.html
> it appears to me that we need not open that can of worms (and I'd much
> rather not muddy the licensing waters that way, regardless of any
> arguments about whether it would hurt or not...)
>
> As near as I can tell, we *could* develop a self-contained installation
> package for PG+cygwin without any licensing problem.  So that set of
> problems could be solved with a reasonable amount of work.  I'm still
> unclear on whether there are serious technical problems (performance,
> stability) with using cygwin.

The last time I tried to play with it, any sort of load tended to blow
away the whole IPC side of things ... it was stable to "play with", but
for any *serious* work ... this may have changed though, as it has been
awhile since I played with it last ...

Re: Path to PostgreSQL portabiliy

Lamar Owen <lamar.owen@wgcr.org> — 2002-05-08T18:49:39Z

On Wednesday 08 May 2002 11:37 am, Thomas Lockhart wrote:
> 1) cygwin is licensed under GPL. So is GNU/Linux, which provides the
> same APIs as cygwin does. Linux does not pollute application licenses,
> presumably because Linux itself is not *required* to run the

The Linux kernel is not under a pure GPL.  

COPYING in the kernel source says this, prepended to the GPL:
   NOTE! This copyright does *not* cover user programs that use kernel
 services by normal system calls - this is merely considered normal use
 of the kernel, and does *not* fall under the heading of "derived work".
 Also note that the GPL below is copyrighted by the Free Software
 Foundation, but the instance of code that it refers to (the Linux
 kernel) is copyrighted by me and others who actually wrote it.

 Also note that the only valid version of the GPL as far as the kernel
 is concerned is _this_ particular version of the license (ie v2, not
 v2.2 or v3.x or whatever), unless explicitly otherwise stated.

                        Linus Torvalds

--------------------------------------------------------------------------

Does cygwin make the same statement?

> 2) If (1) does not exempt the PostgreSQL app from GPL polution, then why
> not distribute PostgreSQL on Windows using a GPL license? 

[snip]

> 3) If (2) is the case, then development could continue under the BSD
> license, since developers could use the BSD-original code for their
> development work. So there is no risk of "backflow polution".

Can PostgreSQL, Inc be the GPL distributor for these purposes, being a 
separate entity from the PostgreSQL Global Development Group?
-- 
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

Re: Path to PostgreSQL portabiliy

Paul Ramsey <pramsey@refractions.net> — 2002-05-08T19:53:57Z

mlw wrote:
>
> No matter what steps you take, cygwin will not be seen by Windows users as
> anything but a sloppy/messy/horrible hack. It is a fact of life. You are
> welcome to disagree, but I assure you it is true.

Just to clarify here: is it confirmed that having the complete cygwin
distribution is a necessary condition to having a running PostgreSQL on
windows? Is it not possible that, having built postgresql with the full
cygwin, it would be possible to make a nice clean setup.exe package
which bundles the postgresql executables, the required cygwin dlls and
other niceties into an easy install package? Given that, I do not think
your putative windows user would care at all about what was going on
under the covers. As long as the install was clean, there were utilities
(pgadmin?) to start working with the database right away, and things
"just worked", the ugliness (or exquisite symmetry... I am not an
expert) of the fork() implementation really would not be an issue :)

Of course, an imaginary beautiful packaging regime hinges on the
possibility of bundling the cygwin api libraries cleanly without
bundling all the rest of the cygwin scruft (unix directory heirarchy,
etc etc). Anyone have any light to shed on cygwin's "packagability"?

P.

Re: Path to PostgreSQL portabiliy

mlw <markw@mohawksoft.com> — 2002-05-08T20:12:17Z

Paul Ramsey wrote:
> 
> mlw wrote:
> >
> > No matter what steps you take, cygwin will not be seen by Windows users as
> > anything but a sloppy/messy/horrible hack. It is a fact of life. You are
> > welcome to disagree, but I assure you it is true.
> 
> Just to clarify here: is it confirmed that having the complete cygwin
> distribution is a necessary condition to having a running PostgreSQL on
> windows? Is it not possible that, having built postgresql with the full
> cygwin, it would be possible to make a nice clean setup.exe package
> which bundles the postgresql executables, the required cygwin dlls and
> other niceties into an easy install package? Given that, I do not think
> your putative windows user would care at all about what was going on
> under the covers. As long as the install was clean, there were utilities
> (pgadmin?) to start working with the database right away, and things
> "just worked", the ugliness (or exquisite symmetry... I am not an
> expert) of the fork() implementation really would not be an issue :)

Windows users expect to have C:\my programs\postgres as the install location. A
person who has used or looked at MSSQL would expect to deal with the real file
system. The cygwin environment shields the UNIX program from Windows, the
Windows user would expect the program to deal with the system as is.

The Windows user that would install PostgreSQL would expect it to be a real
windows program, but would be savvy enough (and prejudiced enough) to know if
it weren't.

Re: Path to PostgreSQL portabiliy

Joel Burton <joel@joelburton.com> — 2002-05-08T22:09:41Z

> -----Original Message-----
> From: pgsql-hackers-owner@postgresql.org
> [mailto:pgsql-hackers-owner@postgresql.org]On Behalf Of Paul Ramsey
> Sent: Wednesday, May 08, 2002 3:54 PM
> To: mlw
> Cc: PostgreSQL-development
> Subject: Re: [HACKERS] Path to PostgreSQL portabiliy
>
>
> mlw wrote:
> >
> > No matter what steps you take, cygwin will not be seen by
> Windows users as
> > anything but a sloppy/messy/horrible hack. It is a fact of life. You are
> > welcome to disagree, but I assure you it is true.
>
> Just to clarify here: is it confirmed that having the complete cygwin
> distribution is a necessary condition to having a running PostgreSQL on
> windows? Is it not possible that, having built postgresql with the full
> cygwin, it would be possible to make a nice clean setup.exe package
> which bundles the postgresql executables, the required cygwin dlls and
> other niceties into an easy install package? Given that, I do not think
> your putative windows user would care at all about what was going on
> under the covers. As long as the install was clean, there were utilities
> (pgadmin?) to start working with the database right away, and things
> "just worked", the ugliness (or exquisite symmetry... I am not an
> expert) of the fork() implementation really would not be an issue :)
>
> Of course, an imaginary beautiful packaging regime hinges on the
> possibility of bundling the cygwin api libraries cleanly without
> bundling all the rest of the cygwin scruft (unix directory heirarchy,
> etc etc). Anyone have any light to shed on cygwin's "packagability"?

Certainly, we don't need all of cygwin (eg bison, gcc, perl, et al). We'd
need the dll, sh, rm, and few other things. I'm not sure if it would need to
be in the standard cygwin file structure; I know that you can reconfigure
this when you use cygwin (I used to). In any event, instead of having to
have a novice pick & guess which of >100 packages they need, we could put
together the 5 or 6 they need.

I'm not sure I agree entirely with mlw: some Windows admins will be afraid
of cygwin, but, I'll bet more than a few won't even notice that its being
used (especially if we can change the dir names, provide windows shortcuts
to the commands like initdb, create database, pg_ctl, etc., which would be
trivial to do).

Still unanswered is real data on whether cygwin would be good for serious
production use by real people. However, for the test/play/try-out model, I
think cygwin would be a fine solution, and wouldn't (shouldn't?) require too
much work.

- J.

Re: Path to PostgreSQL portabiliy

Joel Burton <joel@joelburton.com> — 2002-05-08T22:24:51Z

> -----Original Message-----
> From: pgsql-hackers-owner@postgresql.org
> [mailto:pgsql-hackers-owner@postgresql.org]On Behalf Of mlw
> Sent: Wednesday, May 08, 2002 4:12 PM
> To: Paul Ramsey
> Cc: PostgreSQL-development
> Subject: Re: [HACKERS] Path to PostgreSQL portabiliy
>
> Windows users expect to have C:\my programs\postgres as the
> install location. A
> person who has used or looked at MSSQL would expect to deal with
> the real file
> system. The cygwin environment shields the UNIX program from Windows, the
> Windows user would expect the program to deal with the system as is.
>
> The Windows user that would install PostgreSQL would expect it to
> be a real
> windows program, but would be savvy enough (and prejudiced
> enough) to know if
> it weren't.

It's not the nicest thing, but the root for the mini-cygwin/PG could be
c:\program files\postgresql. Then PG itself could be something like
c:\program files\postgresql\bin. Java, for instance, comes packed in
c:\program files\javasoft\_version_number_\bin.

In any event, for people that want to play around, test it out, do some PG
work on their laptop at night, etc., I don't think they'd really care that
it's not a "real" windows program. I'm a dedicated unix weenie, and I have
PG + cygwin on the windows partition of my machines. It's very convenient at
times.

Joel BURTON | joel@joelburton.com | joelburton.com | aim: wjoelburton
Knowledge Management & Technology Consultant

Re: Path to PostgreSQL portabiliy

Nicolas Bazin <nbazin@ingenico.com.au> — 2002-05-09T00:12:52Z

I think that cygwin is just a hack that allows you to distribute a software
developped for UNIX under Windows. I see the point for using it in a company
that wants to have a bigger market and doesn't really care about the speed
of its application (because cygwin slows down your application quite a bit).
But an open source project should try to have the best implementation, most
of all the main site. If you want a port to Windows with cygnus, let other
sattelite projects do it as they already exist, and add links to these
projects to the home page.
May be its time again to dig up this old subject of thread support. Even the
Unix implementation could have a mixed multi-process multi-thread
architecture. The postmaster could start a certain number of processes each
process beeing able to be multi-threaded if the platform supports it. If you
really don't want of threads it is possible to implement a event
demultiplexer loop and each process can benefit of any delay to do something
else. Then you benefit of idle time in the connexion and even after further
optimization you can benefit of idle time during I/O.
One good start point is the GNU Pth library that implements cooperative
threads. It's a good start because it is supported on many platforms and
it's easier to implement thread support step by step: cooperative in an
event demultiplexing way and then preemptive. Pth has a Posix layer to keep
all things more standard.

Regards,
Nicolas

----- Original Message -----
From: "Paul Ramsey" <pramsey@refractions.net>
To: "mlw" <markw@mohawksoft.com>
Cc: "PostgreSQL-development" <pgsql-hackers@postgresql.org>
Sent: Thursday, May 09, 2002 5:53 AM
Subject: Re: [HACKERS] Path to PostgreSQL portabiliy

> mlw wrote:
> >
> > No matter what steps you take, cygwin will not be seen by Windows users
as
> > anything but a sloppy/messy/horrible hack. It is a fact of life. You are
> > welcome to disagree, but I assure you it is true.
>
> Just to clarify here: is it confirmed that having the complete cygwin
> distribution is a necessary condition to having a running PostgreSQL on
> windows? Is it not possible that, having built postgresql with the full
> cygwin, it would be possible to make a nice clean setup.exe package
> which bundles the postgresql executables, the required cygwin dlls and
> other niceties into an easy install package? Given that, I do not think
> your putative windows user would care at all about what was going on
> under the covers. As long as the install was clean, there were utilities
> (pgadmin?) to start working with the database right away, and things
> "just worked", the ugliness (or exquisite symmetry... I am not an
> expert) of the fork() implementation really would not be an issue :)
>
> Of course, an imaginary beautiful packaging regime hinges on the
> possibility of bundling the cygwin api libraries cleanly without
> bundling all the rest of the cygwin scruft (unix directory heirarchy,
> etc etc). Anyone have any light to shed on cygwin's "packagability"?
>
> P.
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/users-lounge/docs/faq.html
>
>

Re: Path to PostgreSQL portabiliy

Lincoln Yeoh <lyeoh@pop.jaring.my> — 2002-05-09T07:34:06Z

Who really is your target "market" on the windows platform? Microsoft 
Access users (many)? MySQL users(insignificant?)? MSSQL (many)?

Assuming that the postgresql team isn't getting lots of money or resources 
to do it. I don't see why you would want to invest a lot to support windows 
from a long term point of view. Windows can be a costly platform to support.

Because if you become a serious threat, Microsoft can rip the rug from 
beneath you any chance they get. Also Microsoft WILL always change their 
APIs. They're not stupid. If Microsoft freezes their APIs they will end up 
like "yet another BIOS manufacturer", and bye bye profit margins. Microsoft 
will strive to keep it a proprietary AND changing API.

Windows is rather different operationally. Automating vacuum etc on windows 
is going to be different. Starting postgresql as a service is going to be 
different as well. Same for uninstalling. So support requests are going to 
be different.

If your target market is consumer - Windows consumer users also have 
different expectations. Most will want nicer GUIs (those that don't care 
won't mind running Postgresql elsewhere).

BTW if your target market is a bit higher end - typically those that "must 
use" windows also "must use" MSSQL/Oracle/etc. You will thus have to build 
brand recognition for Postgresql on Windows.

All this will cost you.

That said, is it easier to support only Windows NT/2000 and forget about 
Win9x? The bigger dbs don't support win9x either (how does Oracle/DB2 
support NT? They seem to work ok). Leave MySQL to the Win9x people ;). BTW 
does MySQL really perform OK on Win9x?

Forget the Cygwin approach. Is there really a market for that? Unless 
things have got a lot easier, installing Cygwin is like installing a new 
O/S just to install your app. And installing and learning a new system has 
got to be one of the major barriers, otherwise people will either buy a new 
USD500 1.5+ GHz pc or use VMware+BSD/Linux+Postgresql ;).

Cheerio,
Link.

At 11:53 AM 5/8/02 -0400, mlw wrote:
>writing software for over 20 years now, and sometimes you just have to hold
>your nose. It would be nice if we could code what we want, the way we want, in
>the language we want, on the platforms we want.
>
>Windows represents a HUGE user base, it also represents a platform for which a
>real good native PostgreSQL should do well. There are, to my knowledge, no 
>good
>and free databases available for Windows.
>
>PostgreSQL on Windows could be very cool as a serious poster child for why
>open-source is the way to go.

Re: Path to PostgreSQL portabiliy

Marc G. Fournier <scrappy@hub.org> — 2002-05-09T11:51:19Z

On Wed, 8 May 2002, Lamar Owen wrote:

> > 3) If (2) is the case, then development could continue under the BSD
> > license, since developers could use the BSD-original code for their
> > development work. So there is no risk of "backflow polution".
>
> Can PostgreSQL, Inc be the GPL distributor for these purposes, being a
> separate entity from the PostgreSQL Global Development Group?

Ummmm ... no?  We tend to be anti-GPL over here, since its anti-business
... gborg would be a good place for any of this ...

Re: Path to PostgreSQL portabiliy

Doug McNaught <doug@wireboard.com> — 2002-05-09T13:51:42Z

"Marc G. Fournier" <scrappy@hub.org> writes:

> Ummmm ... no?  We tend to be anti-GPL over here, since its anti-business

Let's not use loaded terms here.  

-Doug

Re: Path to PostgreSQL portabiliy

Jan Wieck <janwieck@yahoo.com> — 2002-05-09T17:05:58Z

Paul Ramsey wrote:
> mlw wrote:
> >
> > No matter what steps you take, cygwin will not be seen by Windows users as
> > anything but a sloppy/messy/horrible hack. It is a fact of life. You are
> > welcome to disagree, but I assure you it is true.
>
> Just to clarify here: is it confirmed that having the complete cygwin
> distribution is a necessary condition to having a running PostgreSQL on
> windows? Is it not possible that, having built postgresql with the full
> cygwin, it would be possible to make a nice clean setup.exe package

    Well, PostgreSQL goes as far as using system(3) to do "cp -r"
    and stuff. Dunno what you call it, but I'd  say  it's  making
    assumptions that one shouldn't make :-)


Jan

--

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

Re: Path to PostgreSQL portabiliy

Jan Wieck <janwieck@yahoo.com> — 2002-05-09T17:09:24Z

Joel Burton wrote:
> Certainly, we don't need all of cygwin (eg bison, gcc, perl, et al). We'd
> need the dll, sh, rm, and few other things. I'm not sure if it would need to
> be in the standard cygwin file structure; I know that you can reconfigure
> this when you use cygwin (I used to). In any event, instead of having to
> have a novice pick & guess which of >100 packages they need, we could put
> together the 5 or 6 they need.

    Oh,  BTW,  had  anyone  luck  with  loading of user defined C
    functions or the PL handlers under CygWin? I remember  having
    had  trouble  with  that.   When  the  C function uses global
    variables in the backend, things get a bit messy.


Jan

--

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

Re: Path to PostgreSQL portabiliy

Cyril VELTER <cyril.velter@libertysurf.fr> — 2002-05-09T18:00:03Z

From: "Jan Wieck" <janwieck@yahoo.com>
> Joel Burton wrote:
> > Certainly, we don't need all of cygwin (eg bison, gcc, perl, et al).
We'd
> > need the dll, sh, rm, and few other things. I'm not sure if it would
need to
> > be in the standard cygwin file structure; I know that you can
reconfigure
> > this when you use cygwin (I used to). In any event, instead of having to
> > have a novice pick & guess which of >100 packages they need, we could
put
> > together the 5 or 6 they need.
>
>     Oh,  BTW,  had  anyone  luck  with  loading of user defined C
>     functions or the PL handlers under CygWin? I remember  having
>     had  trouble  with  that.   When  the  C function uses global
>     variables in the backend, things get a bit messy.

    I have a 7.1.3 install with cygwin and I'm using pl/pgsql and a custom
type (with accessor written in a C dll). It never cause me any problem.
My custom dll is not using global var in the backend though.

        cyril

Re: Path to PostgreSQL portabiliy

Lamar Owen <lamar.owen@wgcr.org> — 2002-05-09T18:12:16Z

On Thursday 09 May 2002 07:51 am, Marc G. Fournier wrote:
> On Wed, 8 May 2002, Lamar Owen wrote:
> > > 3) If (2) is the case, then development could continue under the BSD
> > > license, since developers could use the BSD-original code for their
> > > development work. So there is no risk of "backflow polution".

> > Can PostgreSQL, Inc be the GPL distributor for these purposes, being a
> > separate entity from the PostgreSQL Global Development Group?

> Ummmm ... no?  We tend to be anti-GPL over here, since its anti-business
> ... gborg would be a good place for any of this ...

I can see my feeble attempt at humor fell flat.  Sorry.
-- 
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

Threads vs processes - The Apache Way (Re: Path to PostgreSQL portabiliy)

Robert <robert@robert.cz> — 2002-05-10T06:02:26Z

Hi,

  Win32 & threads support are both going to be a lot of work and maybe
we'll need in the future one or both - is there any chance Postgres
developers look at the Apache experience? Briefly, Apache 2 had the some
problems as are discussed here (need to support Win, problems with Win32
fork, questionable cygwin etc) and they decided to solve it once and for
all with their Apache Portable Runtime and Multi-Processing Modules. APR
was already mentioned here - now how about MPMs?

- Robert

PS Relevant links:

http://httpd.apache.org/docs-2.0/mpm.html
http://httpd.apache.org/docs-2.0/new_features_2_0.html

PS2 It took them some three years to release Apache 2 so it's probable
not that easy - but you knew that already.

PS3 And when talking about Win32 Postgres uses, don't forget there might
be a large number of people who would use Posgtres embeded in accounting
and many other packages - it can be single user Win98, but it might
still need decent SQL backend (subqueries, user functions for all kind
of CDROM catalogs etc). So when doing major rearchitecture of Postgres,
it might be usefull to plan for a bit of modularity maybe like in
Mozilla when you can drop UI and use just the layout engine or just the
JavaScript etc.

Re: Threads vs processes - The Apache Way (Re: Path to PostgreSQL

mlw <markw@mohawksoft.com> — 2002-05-10T11:13:04Z

Robert wrote:
> 
> Hi,
> 
>   Win32 & threads support are both going to be a lot of work and maybe
> we'll need in the future one or both - is there any chance Postgres
> developers look at the Apache experience? Briefly, Apache 2 had the some
> problems as are discussed here (need to support Win, problems with Win32
> fork, questionable cygwin etc) and they decided to solve it once and for
> all with their Apache Portable Runtime and Multi-Processing Modules. APR
> was already mentioned here - now how about MPMs?

I am starting to come to the conclusion that the PostgreSQL group is satisfied
with cygwin, and the will to create a native Win32 version does not exist
outside of a few organizations that are paying developers to create one.

Without some buy-in from the core team, I'm not sure I am willing to spend my
time on it. If someone would be willing to fund the 100 or so man-hours
required to do it, then that would be a different story.

pgAdmin2 to be included in Dev-C++

Jean-Michel POURE <jm.poure@freesurf.fr> — 2002-05-10T11:57:11Z

Le Vendredi 10 Mai 2002 13:13, mlw a écrit :
> I am starting to come to the conclusion that the PostgreSQL group is
> satisfied with cygwin, and the will to create a native Win32 version does
> not exist outside of a few organizations that are paying developers to
> create one.

The more important is get a Windows version on the way. pgAdmin2, PostgreSQL 
Windows GUI, will soon be included in the Dev-C++ development environment, as 
per discussion with Colin Laplace.

Native tools for Windows can have a huge success. Dev-C++ had 1.200.000 hits 
over the last years.

> Without some buy-in from the core team, I'm not sure I am willing to spend
> my time on it. If someone would be willing to fund the 100 or so man-hours
> required to do it, then that would be a different story.

I suggest we focuss on providing a minimal PostgreSQL + Cygwin layer at first. 
This will give you the required user base to transform PostgreSQL into a 
multi-platform RDBMS.

If we add together direct downloads on http://www.postgresql.org and from 
partner sites (Dec-C++ on http://www.bloodshed.net),  we could well reach the 
number of 1.000.000 downloads a year under the Windows platform.

Cheers,
Jean-Michel

Re: pgAdmin2 to be included in Dev-C++

mlw <markw@mohawksoft.com> — 2002-05-10T12:06:56Z

Jean-Michel POURE wrote:
> > Without some buy-in from the core team, I'm not sure I am willing to spend
> > my time on it. If someone would be willing to fund the 100 or so man-hours
> > required to do it, then that would be a different story.
> 
> I suggest we focuss on providing a minimal PostgreSQL + Cygwin layer at first.
> This will give you the required user base to transform PostgreSQL into a
> multi-platform RDBMS.

Sorry, I'm not interested in a cygwin version of PostgreSQL. I think it will do
more harm than good. If we make it something that people want to try, and then
they TRY it, they will find that is sucks, then we lose. It is very hard to
remove the bad taste in ones mouth of a poor product. Think Yugo.

I have no patience with designed to fail projects, certainly not with my time.
PostgreSQL+cygwin is a loser. If I am going to invest my time and effort, I
want it to be great.

Put it this way. The run of the mill Windows developer will be using MSDN. With
MSDN comes MSSQL. To the developer, it is largely free to setup MSSQL to do
development work.

OK, a conscientious developer will explore options. They will install various
systems and try them. Given a cygwin+PostgreSQL system, MSSQL, MySQL, Oracle,
DB2, etc. MSSQL will win. MSSQL will win over Oracle for cost and ease of
setup. DB2 will lose, similarly to Oracle. MySQL will lose because it sucks.
PostgreSQL+cygwin will lose because it will also suck.

The idea is to "sway" Microsoft developers to open source, not give them
ammunition of why they think it sucks.

Re: pgAdmin2 to be included in Dev-C++

Jean-Michel POURE <jm.poure@freesurf.fr> — 2002-05-10T12:37:03Z

Le Vendredi 10 Mai 2002 14:06, mlw a écrit :
> Sorry, I'm not interested in a cygwin version of PostgreSQL. I think it
> will do more harm than good. If we make it something that people want to
> try, and then they TRY it, they will find that is sucks, then we lose. It
> is very hard to remove the bad taste in ones mouth of a poor product. Think
> Yugo.

Cygwin is very stable. Its community is relatively small but very actuve. We 
could well provide a unique installer to "hide" Cygwin from the user. This 
can be done compiling Cygwin.dll in a separate user space, as per discussion 
with Dave Page.

> I have no patience with designed to fail projects, certainly not with my
> time. PostgreSQL+cygwin is a loser. If I am going to invest my time and
> effort, I want it to be great.

I agree a native Windows PostgreSQL would be better.

> OK, a conscientious developer will explore options. They will install
> various systems and try them. Given a cygwin+PostgreSQL system, MSSQL,
> MySQL, Oracle, DB2, etc. MSSQL will win. MSSQL will win over Oracle for
> cost and ease of setup. DB2 will lose, similarly to Oracle. MySQL will lose
> because it sucks. PostgreSQL+cygwin will lose because it will also suck.

MySQL under Windows is based on Cygwin.
MySQL sucks  and has a 'huge" success.

So let's do it in three moves :

- first move : gain a large audience providing a stable release of Cygwin + 
PostgreSQL. This could be done within days ... not weeks. This will be much 
better than MySQL.

- second move : release a bundle of pgAdmin2 + PostgreSQL on 
http://www.postgresql.org, Bloodshed and other sites.

- third move : based on 1.000.000 downloads and 100.000 users, feed the 
community with more developpers, more ideas and more Windows native 
source-code. So you wron't say "I am alone".

"Rome ne s'est pas faite en une nuit".
Cheers,
Jean-michel

Re: pgAdmin2 to be included in Dev-C++

Nikolay Mihaylov <pg@nmmm.nu> — 2002-05-10T12:53:57Z

Hi all

Do u know that there are huge ammount of PRODUCTION(!!!) Windows NT
servers runnini apache , php and mysql? Just because the administrators
are lame, or because some companies cant afford more than one server,
and before they decided to use Windows NT (because they did not knew
about UNIX/Linux/FreeBSD). This is the reality.

One more thing - development for PgSQL is quite dificult just because it
does not runs on Windows 9X. There are huge ammount of development
servers running Win 9X, IIS, PHP and MySQL.

A Windows port for postgres will be great. There were before a postgres
installation for wndows but it does not worked properly.

Is not important HOW stable will Windows version work. For example MySQL
for Win is quite UNSTABLE too. The more important is to be VERY EASY to
be installed, thats all.

Nikolay.


-----------------------------------------------------------
The Reboots are for hardware upgrades,
Found more here: http://www.nmmm.nu
Nikolay Mihaylov nmmm@nmmm.nu

-----Original Message-----
From: pgsql-hackers-owner@postgresql.org
[mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of Jean-Michel
POURE
Sent: Friday, May 10, 2002 3:37 PM
To: mlw
Cc: Robert; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] pgAdmin2 to be included in Dev-C++


Le Vendredi 10 Mai 2002 14:06, mlw a écrit :
> Sorry, I'm not interested in a cygwin version of PostgreSQL. I think 
> it will do more harm than good. If we make it something that people 
> want to try, and then they TRY it, they will find that is sucks, then 
> we lose. It is very hard to remove the bad taste in ones mouth of a 
> poor product. Think Yugo.

Cygwin is very stable. Its community is relatively small but very
actuve. We 
could well provide a unique installer to "hide" Cygwin from the user.
This 
can be done compiling Cygwin.dll in a separate user space, as per
discussion 
with Dave Page.

> I have no patience with designed to fail projects, certainly not with 
> my time. PostgreSQL+cygwin is a loser. If I am going to invest my time

> and effort, I want it to be great.

I agree a native Windows PostgreSQL would be better.

> OK, a conscientious developer will explore options. They will install 
> various systems and try them. Given a cygwin+PostgreSQL system, MSSQL,

> MySQL, Oracle, DB2, etc. MSSQL will win. MSSQL will win over Oracle 
> for cost and ease of setup. DB2 will lose, similarly to Oracle. MySQL 
> will lose because it sucks. PostgreSQL+cygwin will lose because it 
> will also suck.

MySQL under Windows is based on Cygwin.
MySQL sucks  and has a 'huge" success.

So let's do it in three moves :

- first move : gain a large audience providing a stable release of
Cygwin + 
PostgreSQL. This could be done within days ... not weeks. This will be
much 
better than MySQL.

- second move : release a bundle of pgAdmin2 + PostgreSQL on 
http://www.postgresql.org, Bloodshed and other sites.

- third move : based on 1.000.000 downloads and 100.000 users, feed the 
community with more developpers, more ideas and more Windows native 
source-code. So you wron't say "I am alone".

"Rome ne s'est pas faite en une nuit".
Cheers,
Jean-michel

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

Re: pgAdmin2 to be included in Dev-C++

mlw <markw@mohawksoft.com> — 2002-05-10T12:57:19Z

Jean-Michel POURE wrote:
> 
> Le Vendredi 10 Mai 2002 14:06, mlw a écrit :
> > Sorry, I'm not interested in a cygwin version of PostgreSQL. I think it
> > will do more harm than good. If we make it something that people want to
> > try, and then they TRY it, they will find that is sucks, then we lose. It
> > is very hard to remove the bad taste in ones mouth of a poor product. Think
> > Yugo.
> 
> Cygwin is very stable. Its community is relatively small but very actuve. We
> could well provide a unique installer to "hide" Cygwin from the user. This
> can be done compiling Cygwin.dll in a separate user space, as per discussion
> with Dave Page.

Here are the problems with cygwin:

(1) GNU license issues.
(2) Does not work well with anti-virus software
(3) Since OS level copy-on-write is negated, process creation is much slower.
(4) Since OS level copy-on-write is negated, memory that otherwise would not be
allocated to the process is forced to be allocated when the parent process data
is copied.

As a product manager, I would not commit to using a cygwin application in
production. Do you know of any long-uptime systems using cygwin? PostgreSQL
would need to run for months. I would view it as a risk.

Lastly, a Windows program is expected to be a Windows program. Native paths
need to be used, like C:\My Database, D:\My Postgres, or something like that.
Native tools must be used to manage it.

> 
> > I have no patience with designed to fail projects, certainly not with my
> MySQL under Windows is based on Cygwin.
> MySQL sucks  and has a 'huge" success.

Define "Success"

> 
> So let's do it in three moves :
> 
> - first move : gain a large audience providing a stable release of Cygwin +
> PostgreSQL. This could be done within days ... not weeks. This will be much
> better than MySQL.

No interest in cygwin, sorry.

Re: pgAdmin2 to be included in Dev-C++

Justin Clift <justin@postgresql.org> — 2002-05-10T13:20:43Z

Hi everyone,

Jean-Michel POURE wrote:
> 
<snip>
> - second move : release a bundle of pgAdmin2 + PostgreSQL on
> http://www.postgresql.org, Bloodshed and other sites.

Don't know if it's useful to know, but a PostgreSQL project got setup on
Sourceforge recently (no CVS), pretty much just so PostgreSQL could be
included in the "Database Foundry" on the Sourceforge site.  :)

http://www.sf.net/projects/pgsql

And then I started a new contract and haven't had time to do anything
with it (oh well).

Regards and best wishes,

Justin Clift

<snip>
> 
> "Rome ne s'est pas faite en une nuit".
> Cheers,
> Jean-michel
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster

-- 
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
   - Indira Gandhi

Re: pgAdmin2 to be included in Dev-C++

Jean-Michel POURE <jm.poure@freesurf.fr> — 2002-05-10T13:26:02Z

Dear Mark,

Agreed except for paths (see below). But now that we agree, why not move to 
Windows in three steps:
1) Release a minimal Cygwin + PostgreSQL installer,
2) Have 100.000 downloads or more Windows developpers,
3) Work as a team on a Windows port.

By the way : Cygwin accepts both Windows AND Unix paths depending on 
installation options. Cygwin is able to understand C:\program 
files\postgresql\var\lib\pgsql, /cygdrive/../var/lib/pgsql or simply 
/var/lib/pgsql.

Cheers,
Jean-Michel

> Here are the problems with cygwin:
> (1) GNU license issues.
> (2) Does not work well with anti-virus software
> (3) Since OS level copy-on-write is negated, process creation is much
> slower. (4) Since OS level copy-on-write is negated, memory that otherwise
> would not be allocated to the process is forced to be allocated when the
> parent process data is copied.
> As a product manager, I would not commit to using a cygwin application in
> production. Do you know of any long-uptime systems using cygwin? PostgreSQL
> would need to run for months. I would view it as a risk.
> Lastly, a Windows program is expected to be a Windows program. Native paths
> need to be used, like C:\My Database, D:\My Postgres, or something like
> that. Native tools must be used to manage it.

Re: pgAdmin2 to be included in Dev-C++

mlw <markw@mohawksoft.com> — 2002-05-10T13:33:37Z

Jean-Michel POURE wrote:
> 
> Dear Mark,
> 
> Agreed except for paths (see below). But now that we agree, why not move to
> Windows in three steps:
> 1) Release a minimal Cygwin + PostgreSQL installer,
> 2) Have 100.000 downloads or more Windows developpers,
> 3) Work as a team on a Windows port.
> 
> By the way : Cygwin accepts both Windows AND Unix paths depending on
> installation options. Cygwin is able to understand C:\program
> files\postgresql\var\lib\pgsql, /cygdrive/../var/lib/pgsql or simply
> /var/lib/pgsql.

The point you are missing is that a cygwin version of postgres is unacceptable.
Doing an installer BEFORE commiting to making the system excellent is putting
the cart before the horse.

The LAST thing we want is 100,000+ Windows users downloading PostgreSQL and
getting a cygwin version. 

The first time it doesn't work because of anti-virus software, they'll call it
junk. When they test performance and see that it sucks, they'll remove the
software.

Re: pgAdmin2 to be included in Dev-C++

Jean-Michel POURE <jm.poure@freesurf.fr> — 2002-05-10T13:55:13Z

Le Vendredi 10 Mai 2002 15:33, mlw a écrit :
> The first time it doesn't work because of anti-virus software, they'll call
> it junk. When they test performance and see that it sucks, they'll remove
> the software.

Dear Mark,

PostgreSQL will work well if cygwin.dll is compiled in a separate workspace 
and installed under C:/program files/postgresql and hidden from users.  I 
agree it will not be able to serve a 50 TPS system.

Furthermore : MySQL sucks, Windoze sucks and Microsoft is violating our 
private rights everyday. So if you care for freedom, we are going to release 
this f****** Cygwin minimal installer.

Don't you think my friend? Noone will complain about it. Do you see 
demonstrations in the street against Microsoft? The answer is no.

Therefore, I believe noone will complain about a minimal Cygwin + PostgreSQL 
installer. This will only be the beginning of a complete Windows port.

Which can also be expressed as :
"Il faut laisser le temps au temps"
"Il n'y a pas le feu au lac"

Cheers,
Jean-Michel

Re: pgAdmin2 to be included in Dev-C++

mlw <markw@mohawksoft.com> — 2002-05-10T14:22:57Z

Jean-Michel POURE wrote:
> 
> Le Vendredi 10 Mai 2002 15:33, mlw a écrit :
> > The first time it doesn't work because of anti-virus software, they'll call
> > it junk. When they test performance and see that it sucks, they'll remove
> > the software.
> 
> Dear Mark,
> 
> PostgreSQL will work well if cygwin.dll is compiled in a separate workspace
> and installed under C:/program files/postgresql and hidden from users.  I
> agree it will not be able to serve a 50 TPS system.

Then what is the point? 

> 
> Furthermore : MySQL sucks, Windoze sucks and Microsoft is violating our
> private rights everyday. So if you care for freedom, we are going to release
> this f****** Cygwin minimal installer.

Don't get me wrong, I would love it if Windows were no longer around. I think a
cygwin version of PostgreSQL will not further your objective. Windows users
will not be seeing the cream of the crop, they will be seeing a quick and dirty
hack. In the words of Martin Luther King, Excellence is the best revenge.

The risk you are taking is this: If you rush out a cygwin version of PostgreSQL
there may be a lasting impression that PostgreSQL is of poor quality. 

How will Windows developers create C language function extensions? Using cygwin
and gcc as well? These guys can't do crap without VisualStudio.

Seriously, don't do it. Please don't do it. If we want to make a serious
presence in the Windows market, it is better to take our time and do it well or
not at all.

> 
> Don't you think my friend? Noone will complain about it. Do you see
> demonstrations in the street against Microsoft? The answer is no.
> 
> Therefore, I believe noone will complain about a minimal Cygwin + PostgreSQL
> installer. This will only be the beginning of a complete Windows port.

I completely disagree. Let me ask you. Have you ever used Windows? I mean as
your primary system? Have you ever thrilled at getting something new for your
Windows system? (Like you do with you current system.)

I'm not ashamed to admit I used to love Windows. Before Linux was usable, and
before FreeBSD was unencumbered, it was the best system a user could get for
the money. Windows was fun, especially if you had the SDK/DDK and knew how to
use it.

Think about Linux and Wine. Linux users do not like Wine applications, no
matter how hidden they are. Franken-wine they are called, and fail quickly.
Look at CorelDraw, a miserable failure. Cygwin on Windows is analogous to Wine
on Linux.

A native PostgreSQL on Windows would rock the Windows world. It would kick
MSSQL's butt for many applications. I think you underestimate Windows and
Windows users if you think a cygwin version will satisfy them. The mistake is
thinking that they are the ignorant unwashed masses that so many UNIX people
seem to think they are.

Re: pgAdmin2 to be included in Dev-C++

Jean-Michel POURE <jm.poure@freesurf.fr> — 2002-05-10T14:51:14Z

> Then what is the point?

We need more information about Cygwin. See Jason Tishler mail forwarded by 
Dave Page.

> Don't get me wrong, I would love it if Windows were no longer around. I
> think a cygwin version of PostgreSQL will not further your objective.
> Windows users will not be seeing the cream of the crop, they will be seeing
> a quick and dirty hack. In the words of Martin Luther King, Excellence is
> the best revenge.

Microsoft and MySQL conquered the world with converse ideas : releasing crap. 
Beside, Cygwin is a very good POSIX emulation. So PostgreSQL + Cygwin wron't 
be crap.

> How will Windows developers create C language function extensions? Using
> cygwin and gcc as well? These guys can't do crap without VisualStudio.

Dev-C++ because mingw and Cygwin can coexist.

> Seriously, don't do it. Please don't do it. If we want to make a serious
> presence in the Windows market, it is better to take our time and do it
> well or not at all.

Well... This is where we disagree. We can do BOTH :
- release a fast Cygwin + PostgreSQL installer,
- port PostgreSQL to native Windows.

> I completely disagree. Let me ask you. Have you ever used Windows? I mean
> as your primary system? Have you ever thrilled at getting something new for
> your Windows system? (Like you do with you current system.)

I stopped using Windows a year ago for political reasons. I stopped using 
Windows three years ago in production for non-political reasons. I simply 
could not work with such a bad system.

> I'm not ashamed to admit I used to love Windows. Before Linux was usable,
> and before FreeBSD was unencumbered, it was the best system a user could
> get for the money. Windows was fun, especially if you had the SDK/DDK and
> knew how to use it.

Sorry my friend, at that time I was sleeping with an Apple IIx and later a 
Macintosh. You must have had a hard time debugging Windows 1.0 or 2.0 (which 
I read on the list previously). You must have been very lucky to survive. Now 
I understand your point of view better ...

> A native PostgreSQL on Windows would rock the Windows world. It would kick
> MSSQL's butt for many applications. I think you underestimate Windows and
> Windows users if you think a cygwin version will satisfy them. The mistake
> is thinking that they are the ignorant unwashed masses that so many UNIX
> people seem to think they are.

Agreed. But it wron't be ready before 6 months. Meanwhile I would like to come 
with a suitable solution to release on http://www.bloodshed.net and feed 
hungry developpers that are getting bored with MySQL.

In short, my opinion is 
"Le mieux est l'ennemi du bien"

Cheers,
Jean-Michel

Re: Threads vs processes - The Apache Way (Re: Path to PostgreSQL

Tom Lane <tgl@sss.pgh.pa.us> — 2002-05-10T16:00:38Z

mlw <markw@mohawksoft.com> writes:
> Without some buy-in from the core team, I'm not sure I am willing to spend my
> time on it. If someone would be willing to fund the 100 or so man-hours
> required to do it, then that would be a different story.

You are not going to get any buy-in with such ridiculous claims as that.
If the total cost of a native Windows port were O(100 hours), it'd have
been done long since.  Add a couple zeroes on the end and I'd start to
believe that you might have some grasp of the problem.

			regards, tom lane

Re: Threads vs processes - The Apache Way (Re: Path to PostgreSQL

mlw <markw@mohawksoft.com> — 2002-05-10T16:55:42Z

Tom Lane wrote:
> 
> mlw <markw@mohawksoft.com> writes:
> > Without some buy-in from the core team, I'm not sure I am willing to spend my
> > time on it. If someone would be willing to fund the 100 or so man-hours
> > required to do it, then that would be a different story.
> 
> You are not going to get any buy-in with such ridiculous claims as that.
> If the total cost of a native Windows port were O(100 hours), it'd have
> been done long since.  Add a couple zeroes on the end and I'd start to
> believe that you might have some grasp of the problem.

I was basing my estimates on a couple things. Please feel free to correct me
where I'm wrong. Dann Corbit mentioned a number of, I think I recall, a couple
hundred man-hours for their port.

My approach would be to find all the global variables setup by postmaster, not
all the globals, mind you. Just the ones initialized by postmaster. Move them
to a structure. That structure would be capable of being copied to the child
process.

In the area where forking the postgres process happens, I would ifdef that area
with an "HAS_FORK"  The Windows portion would use CreateProcess. The Windows
version of postgres would contact the postmaster and get its copy of the
globals struct. The code to transfer ownership of sockets, files, and memory
would have to be written also.

I would only minimally change the back-end code, it would still be built with
cygwin tools only directed not to link against the cygwin.dll. (The same goes
for the utilities as well.)

A thin port layer could then be constructed by either implementing sysv/UNIX
replacements, or a more simple API as needed in the code, like your shared
memory and semaphore APIs.

Does that sound like an unworkable plan?