PG+Cygwin Production Experience (was RE: Path to PostgreSQL porta biliy)
Ooops sorry about the last post (all thumbs today)
-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
Sent: 08 May 2002 16:57
To: Thomas Lockhart
Cc: mlw; PostgreSQL-development; Jan Wieck; Marc G. Fournier; Dann
Corbit
Subject: Re: Path to PostgreSQL portabiliyThomas 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...)
Cygwin is not the only additon needed, cygipc will also be needed (GPL)
(see: http://www.neuro.gatech.edu/users/cwilson/cygutils/cygipc/index.html )
I have heard it said that an ipc implementation will be appearing in the
main
cygwin DLL, but have yet to see it.
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
The system has about 30 transactional users on average.
Why am I using NT? IT has decided it is the way.
The major limitation on performance appears to be fork() as this actually
copies the memory, rather than just copy on write. Also I believe it has fix
up some of the file descriptors for things like sockets, and those things
that
have no fd under windows, but do under *nix. This seems to be the only major
performance bottle neck, although I havn't done much comparison testing.
Other limitations are:
Processes - Can only have 62 Children due to WaitForMultipleObjects 64 item
limit. (I'm wondering about tackling this, however it'll be my first
forey into cygwin so don't hold your breath)
Memory - Starts at 256Mb limit, can be increased by a registry key:
//HKCU/Software/Cygnus Solutions/Cygwin/
heap_chunk_in_mb DWORD
As can be seen, this uses Current User so you need to make sure your
ipc-daemon service starts as the correct user as well as the postmaster.
If you use a lot of shared memory, the opstmaster can take a while to start,
but this isn't a problem for me.
As to stability, don't use on Win9x. This is just about usable for
development
but it keeps crashin at ramdom times, especially when restoring from dump
files.
I have never managed to complete make installcheck on 9x.
Sometimes things seem to be broken in a new version of cygwin, to be fixed
by
the next. Just need to test before using. Also I only use plpgsql for server
side programing. I know there are problems building for TCL, and I don't
know
about perl and python.
The only other problems I've had with NT4 are:
a) When running as a service, it wouldn't term in time due to sighup. Fixed
b) As of 7.2.1 (don't know about 7.2, not tried it enough), the following
causes a problem when restoring large amounts of data, which is solved by
just using rename (see previous postings to pgsql-cgywin)
/*
* Prefer link() to rename() here just to be really sure that we
don't
* overwrite an existing logfile. However, there shouldn't be one,
so
* rename() is an acceptable substitute except for the truly
paranoid.
*/
#ifndef __BEOS__
if (link(tmppath, path) < 0)
elog(STOP, "link from %s to %s (initialization of log file
%u, segment %u) failed: %m",
tmppath, path, log, seg);
unlink(tmppath);
#else
if (rename(tmppath, path) < 0)
elog(STOP, "rename from %s to %s (initialization of log file
%u, segment %u) failed: %m",
tmppath, path, log, seg);
#endif
Hope something here helps the discussion,
- Stuart
P.S. I will not be on email Fri-Mon (inclusive), but if anyone wants further
info/discussion on particulars, I will be available from Tuesday
(or some of today).
"Henshall, Stuart - WCP" <SHenshall@westcountrypublications.co.uk> writes:
Cygwin is not the only additon needed, cygipc will also be needed (GPL)
(see: http://www.neuro.gatech.edu/users/cwilson/cygutils/cygipc/index.html )
Good point, but is this a requirement that we could get rid of, now that
we have the SysV IPC stuff somewhat isolated? AFAICT cygipc provides
the SysV IPC API (shmget, semget, etc) --- but if there are usable
equivalents in the basic Cygwin environment, we could probably use them
now.
Considering how often we see the forgot-to-start-cygipc mistake,
removing this requirement would be a clear win.
regards, tom lane
Import Notes
Reply to msg id not found: E2870D8CE1CCD311BAF50008C71EDE8E01F74896@MAIL_EXCHANGEReference msg id not found: E2870D8CE1CCD311BAF50008C71EDE8E01F74896@MAIL_EXCHANGE | Resolved by subject fallback
From: "Tom Lane" <tgl@sss.pgh.pa.us>
"Henshall, Stuart - WCP" <SHenshall@westcountrypublications.co.uk> writes:Cygwin is not the only additon needed, cygipc will also be needed (GPL)
(see:
http://www.neuro.gatech.edu/users/cwilson/cygutils/cygipc/index.html )
Good point, but is this a requirement that we could get rid of, now that
we have the SysV IPC stuff somewhat isolated? AFAICT cygipc provides
the SysV IPC API (shmget, semget, etc) --- but if there are usable
equivalents in the basic Cygwin environment, we could probably use them
now.Considering how often we see the forgot-to-start-cygipc mistake,
removing this requirement would be a clear win.regards, tom lane
In my experience, cygipc is the most tricky part in a postgresql/cygwin
install (mainly because because of access rights problem). Using native call
for sem / shm will be a good step forward (and the API change might make
this quite easy). I've also never been able to start two postmaster instance
on the same box. Doing so is messing shared memory leading to both
postmaster crashing.
cyril
Import Notes
Reference msg id not found: E2870D8CE1CCD311BAF50008C71EDE8E01F74896@MAIL_EXCHANGE
I have found this whole thread very interesting (I'm still not sure
where it is going though :-). But let me throw in some of my thoughts.
A windows version of postgres (whether native of cygwin based) is
important. I have many developers with windows as their desktop OS and
they have a postgres db installed to do development work. Postgres on
cygwin is fine for this need. While I may not trust it in a production
environment it is certainly good enough for development.
A second use we have for postgres on windows is in evals of our product.
We provide an eval version of our software as an InstallShield
installed .exe that includes our code, postgres and the necessary cygwin
parts. People doing evals just want to install the eval on their
everyday machine (most likely running windows) and it needs to be dead
simple to install. This can be done with postgres and cygwin. In this
example again the current postgres+cygwin works well enough for our
evals. Again I wouldn't run the production version in this environment,
but it is good enough for an eval.
Our eval does show that it is possible to repackage postgres plus the
parts of cygwin it needs into a nice installer and have it work. (It is
a lot of work but is certainly possible). In fact in our eval install
we even use cygrunsrv to install postgres as a windows service.
The biggest problem we have had is the fact that the utility scripts
(like pg_ctl, createdb, etc) are all shell scripts that call a whole
host of other utilities. It is pretty straight forward to package up
the postgres executable and the libraries it needs from cygwin. It is a
whole different problem making sure you have a standard unix style shell
environment with all the utilities installed so that you can run the
shell scripts.
thanks,
--Barry
Tom Lane wrote:
Show quoted text
"Henshall, Stuart - WCP" <SHenshall@westcountrypublications.co.uk> writes:
Cygwin is not the only additon needed, cygipc will also be needed (GPL)
(see: http://www.neuro.gatech.edu/users/cwilson/cygutils/cygipc/index.html )Good point, but is this a requirement that we could get rid of, now that
we have the SysV IPC stuff somewhat isolated? AFAICT cygipc provides
the SysV IPC API (shmget, semget, etc) --- but if there are usable
equivalents in the basic Cygwin environment, we could probably use them
now.Considering how often we see the forgot-to-start-cygipc mistake,
removing this requirement would be a clear win.regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly
Import Notes
Reference msg id not found: E2870D8CE1CCD311BAF50008C71EDE8E01F74896@MAIL_EXCHANGE
Tom Lane wrote:
"Henshall, Stuart - WCP" <SHenshall@westcountrypublications.co.uk> writes:
Cygwin is not the only additon needed, cygipc will also be needed (GPL)
(see: http://www.neuro.gatech.edu/users/cwilson/cygutils/cygipc/index.html )Good point, but is this a requirement that we could get rid of, now that
we have the SysV IPC stuff somewhat isolated? AFAICT cygipc provides
the SysV IPC API (shmget, semget, etc) --- but if there are usable
equivalents in the basic Cygwin environment, we could probably use them
now.Considering how often we see the forgot-to-start-cygipc mistake,
removing this requirement would be a clear win.regards, tom lane
There is some work going on within cygwin to make the separate cygipc
stuff less of a problem. They are trying to integrate SysV IPC
functionality it into the core cygwin.dll. However because of licensing
issues (the current cygipc code is GPL and RedHat currently as the
copyright holder on the core cygwin code releases it for a fee under
other licenses in addition to the GPL) there are some problems with
doing that.
thanks,
--Barry
Show quoted text
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly
Import Notes
Reference msg id not found: E2870D8CE1CCD311BAF50008C71EDE8E01F74896@MAIL_EXCHANGE
Barry Lind wrote:
I have found this whole thread very interesting (I'm still not sure
where it is going though :-). But let me throw in some of my thoughts.A windows version of postgres (whether native of cygwin based) is
important. I have many developers with windows as their desktop OS and
they have a postgres db installed to do development work. Postgres on
cygwin is fine for this need. While I may not trust it in a production
environment it is certainly good enough for development.A second use we have for postgres on windows is in evals of our product.
We provide an eval version of our software as an InstallShield
installed .exe that includes our code, postgres and the necessary cygwin
parts. People doing evals just want to install the eval on their
everyday machine (most likely running windows) and it needs to be dead
simple to install. This can be done with postgres and cygwin. In this
example again the current postgres+cygwin works well enough for our
evals. Again I wouldn't run the production version in this environment,
but it is good enough for an eval.Our eval does show that it is possible to repackage postgres plus the
parts of cygwin it needs into a nice installer and have it work. (It is
a lot of work but is certainly possible). In fact in our eval install
we even use cygrunsrv to install postgres as a windows service.The biggest problem we have had is the fact that the utility scripts
(like pg_ctl, createdb, etc) are all shell scripts that call a whole
host of other utilities. It is pretty straight forward to package up
the postgres executable and the libraries it needs from cygwin. It is a
whole different problem making sure you have a standard unix style shell
environment with all the utilities installed so that you can run the
shell scripts.
Do I read this right? You wrap the binary eval version of
your product, the binary PostgreSQL and CygWin including some
of the utility programs into one InstallShield .exe and ship
that?
Hmmm, PostgreSQL's license is totally fine with that. And
your program is your program. But as far as I know bundling
with CygWin like this costs money. So you pay license fees to
RedHat for shipping eval copies of your product and don't see
any value in a native Windows port? Nobel, nobel, or does
your product have such an outstanding eval/sell ratio that it
doesn't matter?
Jan
thanks,
--BarryTom Lane wrote:
"Henshall, Stuart - WCP" <SHenshall@westcountrypublications.co.uk> writes:
Cygwin is not the only additon needed, cygipc will also be needed (GPL)
(see: http://www.neuro.gatech.edu/users/cwilson/cygutils/cygipc/index.html )Good point, but is this a requirement that we could get rid of, now that
we have the SysV IPC stuff somewhat isolated? AFAICT cygipc provides
the SysV IPC API (shmget, semget, etc) --- but if there are usable
equivalents in the basic Cygwin environment, we could probably use them
now.Considering how often we see the forgot-to-start-cygipc mistake,
removing this requirement would be a clear win.regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #