Re: PG+Cygwin Production Experience (was RE: Path to PostgreSQL - Mailing list pgsql-hackers
From | Barry Lind |
---|---|
Subject | Re: PG+Cygwin Production Experience (was RE: Path to PostgreSQL |
Date | |
Msg-id | 3CDAA0E3.5060706@xythos.com Whole thread Raw |
In response to | Re: PG+Cygwin Production Experience (was RE: Path to PostgreSQL porta biliy) (Tom Lane <tgl@sss.pgh.pa.us>) |
Responses |
Re: PG+Cygwin Production Experience (was RE: Path to PostgreSQL
|
List | pgsql-hackers |
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 anInstallShield 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: > "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 >
pgsql-hackers by date: