Re: PG+Cygwin Production Experience (was RE: Path to PostgreSQL porta biliy) - Mailing list pgsql-hackers

From Cyril VELTER
Subject Re: PG+Cygwin Production Experience (was RE: Path to PostgreSQL porta biliy)
Date
Msg-id 006101c1f765$ae6b7500$6901a8c0@cvfixe
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>)
List pgsql-hackers
>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





pgsql-hackers by date:

Previous
From: mlw
Date:
Subject: Re: How much work is a native Windows application?
Next
From: Tom Lane
Date:
Subject: Re: Queries using rules show no rows modified?