Обсуждение: Re: PG+Cygwin Production Experience (was RE: Path to PostgreSQL porta biliy)

"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

>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

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




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

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
> 

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
includingsome   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
productand don't see   any value in a native Windows port?  Nobel,  nobel,  or  does   your product have such an
outstandingeval/sell ratio that it   doesn't matter?
 


Jan

>
> 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
> >
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/users-lounge/docs/faq.html
>


--

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