Skip site navigation (1) Skip section navigation (2)

Re: FATAL: semctl(1672698088, 12, SETVAL, 0) failed

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Qingqing Zhou <zhouqq(at)cs(dot)toronto(dot)edu>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: FATAL: semctl(1672698088, 12, SETVAL, 0) failed
Date: 2006-03-01 03:08:37
Message-ID: 200603010308.k2138bO09022@candle.pha.pa.us (view raw or flat)
Thread:
Lists: pgsql-bugs
Qingqing Zhou wrote:
> 
> "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us> wrote
> > > In port/win32.h, we have
> > >
> > > #undef EAGAIN
> > > #undef EINTR
> > > #define EINTR WSAEINTR
> > > #define EAGAIN WSAEWOULDBLOCK
> > >
> > > What's the rationale of doing so?
> >
> > We did this so that our code could refer to EINTR/EAGAIN without
> > port-specific tests.
> >
> 
> AFAICS, by doing so, the EINTR/EAGAIN will be translated into
> WSAINTR/WSAEWOULDBLOCK through *all* the backend code. That's seems not
> appropriate for the code not involving any socket stuff ... I think we need
> a fix here.

Uh, how do we handle it now?  I thought we did just that.

> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/waitformultipleobjectsex.asp
> >
> > and it isn't clear what return failure values it has.  We certainly
> > could loop on WSAEINTR.  Can you test it?
> >
> 
> Yeah, looking at other code of using semop(), we could plug in a loop in the
> win32 semctl():
> 
>    /* Quickly lock/unlock the semaphore (if we can) */
> + do
> + {
> +    errStatus = semop(semId, &sops, 1);
> + } while (errStatus < 0 && errno == EINTR);
> 
>    if (semop(semId, &sops, 1) < 0)
>     return -1;
> 
> But:
> (1) The EINTR problem happens rather rare, so testing it is difficult;
> (2)  I would rather not doing the above changes before we understand what's
> happened here, especially when we have seen a EAGAIN reported here.

OK, so how do we find the answer?

-- 
  Bruce Momjian   http://candle.pha.pa.us
  SRA OSS, Inc.   http://www.sraoss.com

  + If your life is a hard drive, Christ can be your backup. +

In response to

Responses

pgsql-bugs by date

Next:From: Qingqing ZhouDate: 2006-03-01 03:20:52
Subject: Re: FATAL: semctl(1672698088, 12, SETVAL, 0) failed
Previous:From: Qingqing ZhouDate: 2006-03-01 02:08:58
Subject: Re: FATAL: semctl(1672698088, 12, SETVAL, 0) failed

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group