Thread: Re: [CYGWIN] ipc-daemon
Jason Tishler writes:
> 1. If ipc-daemon is not running, then cygipc's shmget() will return
> EACCES.
> 2. This causes PostgreSQL's InternalIpcMemoryCreate() to return
> NULL.
> 3. This causes PostgreSQL's PGSharedMemoryCreate() to spin looking
> for accessible shared memory which it will never find.
To me, this is a bug in PostgreSQL. A comment in
InternalIpcMemoryCreate() says
* Fail quietly if error indicates a collision with existing
* segment. One would expect EEXIST, given that we said IPC_EXCL,
* but perhaps we could get a permission violation instead?
I tend to think that the answer to that question is No.
> After reading the shmget() man page, I choose to return ENOSPC. Is
> there a better choice? Such as ENOMEM?
My first thought was ENOSYS (system call not implemented -- what BSD
kernels tend to return if you didn't compile them with SysV IPC support),
but that isn't a clearly superior choice either. Fixing PostgreSQL is
probably better and quicker to yield a return.
--
Peter Eisentraut peter_e@gmx.net
Peter Eisentraut <peter_e@gmx.net> writes:
> Jason Tishler writes:
>> 1. If ipc-daemon is not running, then cygipc's shmget() will return
>> EACCES.
>> 2. This causes PostgreSQL's InternalIpcMemoryCreate() to return
>> NULL.
>> 3. This causes PostgreSQL's PGSharedMemoryCreate() to spin looking
>> for accessible shared memory which it will never find.
> To me, this is a bug in PostgreSQL.
I disagree: just because cygipc returns error codes chosen at random
doesn't mean that we should neglect the clear meaning of an error code.
If a normal Unix system were to return EACCES here, the clear
implication would be that there is an existing segment that we do not
have permission to access. I don't see how "cygipc isn't running"
can reasonably be translated into "permission denied".
>> After reading the shmget() man page, I choose to return ENOSPC. Is
>> there a better choice? Such as ENOMEM?
> My first thought was ENOSYS (system call not implemented -- what BSD
> kernels tend to return if you didn't compile them with SysV IPC support),
> but that isn't a clearly superior choice either.
If you can detect that cygipc is not running, then ENOSYS seems the
best choice for reporting that. (ENOSPC would be misleading too.)
If it's impractical to fix cygipc then I'd grudgingly go along with
if (errno == EEXIST
#ifndef __CYWGIN__ /* cygipc is broken */
|| errno == EACCES
#endif
#ifdef EIDRM
|| errno == EIDRM
#endif
)
return NULL;
regards, tom lane
Tom, Peter, On Mon, Nov 04, 2002 at 02:43:01PM -0500, Tom Lane wrote: > Peter Eisentraut <peter_e@gmx.net> writes: > > To me, this is a bug in PostgreSQL. > > I disagree: just because cygipc returns error codes chosen at random > doesn't mean that we should neglect the clear meaning of an error > code. If a normal Unix system were to return EACCES here, the clear > implication would be that there is an existing segment that we do not > have permission to access. I don't see how "cygipc isn't running" can > reasonably be translated into "permission denied". > > [snip] > > > My first thought was ENOSYS (system call not implemented -- what BSD > > kernels tend to return if you didn't compile them with SysV IPC > > support), but that isn't a clearly superior choice either. > > If you can detect that cygipc is not running, then ENOSYS seems the > best choice for reporting that. (ENOSPC would be misleading too.) > > If it's impractical to fix cygipc then I'd grudgingly go along with > > if (errno == EEXIST > #ifndef __CYWGIN__ /* cygipc is broken */ > || errno == EACCES > #endif > #ifdef EIDRM > || errno == EIDRM > #endif > ) > return NULL; Thanks for your feedback. I will take this to the Cygwin list and see what happens. Unfortunately, the cygipc maintainer is "AWOL" right now because of Ph.D. thesis commitments. Hence, even if I can get the Cygwin community to agree to this change, there may not be an official cygipc release for a while. Thanks, Jason -- GPG key available on key servers or http://www.tishler.net/jason/gpg.txt
Attachment
Tom Lane writes: > I disagree: just because cygipc returns error codes chosen at random > doesn't mean that we should neglect the clear meaning of an error code. > If a normal Unix system were to return EACCES here, the clear > implication would be that there is an existing segment that we do not > have permission to access. OK, but shouldn't the looping for a new segment terminate sometime? As it stands it will wrap around and run forever. If we catch it before it wraps and generate an error to the effect that no segments appear to be free, it might serve us. -- Peter Eisentraut peter_e@gmx.net
Peter Eisentraut <peter_e@gmx.net> writes:
> Tom Lane writes:
>> I disagree: just because cygipc returns error codes chosen at random
>> doesn't mean that we should neglect the clear meaning of an error code.
>> If a normal Unix system were to return EACCES here, the clear
>> implication would be that there is an existing segment that we do not
>> have permission to access.
> OK, but shouldn't the looping for a new segment terminate sometime? As it
> stands it will wrap around and run forever.
Hm. It would be reasonable to put a limit on the number of attempts,
probably. (There's a similar limit on attempts to create a lockfile.)
regards, tom lane
Tom,
Peter,
On Mon, Nov 04, 2002 at 03:05:25PM -0500, Jason Tishler wrote:
> On Mon, Nov 04, 2002 at 02:43:01PM -0500, Tom Lane wrote:
> > If you can detect that cygipc is not running, then ENOSYS seems the
> > best choice for reporting that. (ENOSPC would be misleading too.)
>
> Thanks for your feedback. I will take this to the Cygwin list and see
> what happens.
I happy to report that the above has been accomplished:
http://cygwin.com/ml/cygwin-announce/2002-11/msg00025.html
Hopefully, the Cygwin initdb and postmaster hang posts will be a thing
of the past. Unfortunately, they probably will be replaced by questions
like:
Why does initdb fail with "IpcMemoryCreate: shmget(...) failed:
Function not implemented?"
Jason
--
PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers
Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6
At least that is an FAQ item. --------------------------------------------------------------------------- Jason Tishler wrote: > Tom, > Peter, > > On Mon, Nov 04, 2002 at 03:05:25PM -0500, Jason Tishler wrote: > > On Mon, Nov 04, 2002 at 02:43:01PM -0500, Tom Lane wrote: > > > If you can detect that cygipc is not running, then ENOSYS seems the > > > best choice for reporting that. (ENOSPC would be misleading too.) > > > > Thanks for your feedback. I will take this to the Cygwin list and see > > what happens. > > I happy to report that the above has been accomplished: > > http://cygwin.com/ml/cygwin-announce/2002-11/msg00025.html > > Hopefully, the Cygwin initdb and postmaster hang posts will be a thing > of the past. Unfortunately, they probably will be replaced by questions > like: > > Why does initdb fail with "IpcMemoryCreate: shmget(...) failed: > Function not implemented?" > > Jason > > -- > PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers > Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 > > ---------------------------(end of broadcast)--------------------------- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Richard, On Sat, Nov 16, 2002 at 02:27:22PM -0800, Richard Pais wrote: > Just an explanation in the FAQ that the ipc-daemon is not running > won't suffice. Because in my case I had ipc-daemon (version 1.11) > running and it still hung (Jason's patch reported the IpcMemoryCreate > error). Only when I downgraded to version 1.09 (office) and upgraded > to 1.13 (home) did initdb succeed. So I'd suggest also covering this > scenario. If you feel strongly about the above, then submit a patch to pgsql-patches@ for consideration. Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6
Just an explanation in the FAQ that the ipc-daemon is not running won't suffice. Because in my case I had ipc-daemon (version 1.11) running and it still hung (Jason's patch reported the IpcMemoryCreate error). Only when I downgraded to version 1.09 (office) and upgraded to 1.13 (home) did initdb succeed. So I'd suggest also covering this scenario.
Thanks,
Richard
Bruce Momjian <pgman@candle.pha.pa.us> wrote:
At least that is an FAQ item.
---------------------------------------------------------------------------
Jason Tishler wrote:
> Tom,
> Peter,
>
> On Mon, Nov 04, 2002 at 03:05:25PM -0500, Jason Tishler wrote:
> > On Mon, Nov 04, 2002 at 02:43:01PM -0500, Tom Lane wrote:
> > > If you can detect that cygipc is not running, then ENOSYS seems the
> > > best choice for reporting that. (ENOSPC would be misleading too.)
> >
> > Thanks for your feedback. I will take this to the Cygwin list and see
> > what happens.
>
> I happy to report that the above has been accomplished:
>
> http://cygwin.com/ml/cygwin-announce/2002-11/msg00025.html
>
> Hopefully, the Cygwin initdb and postmaster hang posts will be a thing
> of the past. Unfortunately, they probab ly will be replaced by questions
> like:
>
> Why does initdb fail with "IpcMemoryCreate: shmget(...) failed:
> Function not implemented?"
>
> Jason
>
> --
> PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers
> Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
>
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/user s-lounge/docs/faq.html
Do you Yahoo!?
Yahoo! Web Hosting - Let the expert host your site
To get into the FAQ, it should be something that happens _frequently_, hence FAQ. Fact is, cygwin may not even be needed in 7.4 because we are working on a native port. --------------------------------------------------------------------------- Jason Tishler wrote: > Richard, > > On Sat, Nov 16, 2002 at 02:27:22PM -0800, Richard Pais wrote: > > Just an explanation in the FAQ that the ipc-daemon is not running > > won't suffice. Because in my case I had ipc-daemon (version 1.11) > > running and it still hung (Jason's patch reported the IpcMemoryCreate > > error). Only when I downgraded to version 1.09 (office) and upgraded > > to 1.13 (home) did initdb succeed. So I'd suggest also covering this > > scenario. > > If you feel strongly about the above, then submit a patch to > pgsql-patches@ for consideration. > > Jason > > -- > PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers > Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 > > ---------------------------(end of broadcast)--------------------------- > TIP 6: Have you searched our list archives? > > http://archives.postgresql.org > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Bruce, On Mon, Nov 18, 2002 at 10:42:30AM -0500, Bruce Momjian wrote: > To get into the FAQ, it should be something that happens _frequently_, > hence FAQ. Understood. That is why is said "for consideration." > Fact is, cygwin may not even be needed in 7.4 because we are > working on a native port. A Win32 native port in the 7.4 time frame is great news! However, I hope that the Cygwin port will not be deprecated. There are compelling reasons to still have a Cygwin PostgreSQL port just like there is with Python, Perl, Vim, Emacs, etc. On the other hand, I wouldn't mind being put out of the Cygwin PostgreSQL support business... :,) Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6
Jason Tishler wrote: > Bruce, > > On Mon, Nov 18, 2002 at 10:42:30AM -0500, Bruce Momjian wrote: > > To get into the FAQ, it should be something that happens _frequently_, > > hence FAQ. > > Understood. That is why is said "for consideration." > > > Fact is, cygwin may not even be needed in 7.4 because we are > > working on a native port. > > A Win32 native port in the 7.4 time frame is great news! However, I > hope that the Cygwin port will not be deprecated. There are compelling > reasons to still have a Cygwin PostgreSQL port just like there is with > Python, Perl, Vim, Emacs, etc. On the other hand, I wouldn't mind being > put out of the Cygwin PostgreSQL support business... :,) I see no reason to remove cygwin support. I assume they will both continue to exist. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Bruce Momjian writes: > To get into the FAQ, it should be something that happens _frequently_, Just check the pgsql-cygwin archives. We really need a separate list of Constantly Asked Questions for this. -- Peter Eisentraut peter_e@gmx.net