From pgsql-bugs-owner+M14436@postgresql.org Tue Feb 21 22:21:37 2006 Return-path: Received: from ams.hub.org (ams.hub.org [200.46.204.13]) by candle.pha.pa.us (8.11.6/8.11.6) with ESMTP id k1M3La514372 for ; Tue, 21 Feb 2006 22:21:37 -0500 (EST) Received: from postgresql.org (postgresql.org [200.46.204.71]) by ams.hub.org (Postfix) with ESMTP id 3F65267B6A8 for ; Tue, 21 Feb 2006 23:21:32 -0400 (AST) X-Original-To: pgsql-bugs-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by postgresql.org (Postfix) with ESMTP id 39FB99DCBE3 for ; Tue, 21 Feb 2006 23:21:08 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 11699-01 for ; Tue, 21 Feb 2006 23:21:12 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- Received: from floppy.pyrenet.fr (news.pyrenet.fr [194.116.145.2]) by postgresql.org (Postfix) with ESMTP id 271CB9DCABD for ; Tue, 21 Feb 2006 23:21:05 -0400 (AST) Received: by floppy.pyrenet.fr (Postfix, from userid 106) id 90AFD30BB2; Wed, 22 Feb 2006 04:21:09 +0100 (MET) From: "Qingqing Zhou" X-Newsgroups: pgsql.bugs Subject: [BUGS] FATAL: semctl(1672698088, 12, SETVAL, 0) failed Date: Wed, 22 Feb 2006 11:17:51 +0800 Organization: Hub.Org Networking Services Lines: 50 Message-ID: X-Complaints-To: usenet@news.hub.org X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1506 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 To: pgsql-bugs@postgresql.org X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.16 required=5 tests=[AWL=0.160] X-Spam-Score: 0.16 X-Mailing-List: pgsql-bugs List-Archive: List-Help: List-Id: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: Precedence: bulk Sender: pgsql-bugs-owner@postgresql.org Status: ROr I encountered an error when I fast shutdown 8.1.1 on Win2k: FATAL: semctl(1672698088, 12, SETVAL, 0) failed: A blocking operation was interrupted by a call to WSACancelBlockingCall. A similar error on 8.1/win2003 was reported on pgsql-general (sorry, I can't dig out the original post from our web archives): From: Niederland Date: Tues, Dec 13 2005 9:49 am 2005-12-12 20:30:00 FATAL: semctl(50884184, 15, SETVAL, 0) failed: A non-blocking socket operation could not be completed immediately. --- There are two problems here: (1) Why a socket error? In port/win32.h, we have #undef EAGAIN #undef EINTR #define EINTR WSAEINTR #define EAGAIN WSAEWOULDBLOCK What's the rationale of doing so? (2) What's happened here? It may come from PGSemaphoreReset(), and win32 semop() looks like this: ret = WaitForMultipleObjectsEx(2, wh, FALSE, (sops[0].sem_flg & IPC_NOWAIT) ? 0 : INFINITE, TRUE); ... else if (ret == WAIT_OBJECT_0 + 1 || ret == WAIT_IO_COMPLETION) { pgwin32_dispatch_queued_signals(); errno = EINTR; } else if (ret == WAIT_TIMEOUT) errno = EAGAIN; So it seems the EINTR is caused by an incoming signal, the EAGAIN is caused by a TIMEOUT ... any ideas? Regards, Qingqing ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match From pgsql-bugs-owner+M14482@postgresql.org Tue Feb 28 14:05:23 2006 Return-path: Received: from ams.hub.org (ams.hub.org [200.46.204.13]) by candle.pha.pa.us (8.11.6/8.11.6) with ESMTP id k1SJ5Mk19122 for ; Tue, 28 Feb 2006 14:05:22 -0500 (EST) Received: from postgresql.org (postgresql.org [200.46.204.71]) by ams.hub.org (Postfix) with ESMTP id A3FB567B7BF for ; Tue, 28 Feb 2006 15:05:20 -0400 (AST) X-Original-To: pgsql-bugs-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by postgresql.org (Postfix) with ESMTP id DB1559DCB49 for ; Tue, 28 Feb 2006 15:05:04 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 86421-08 for ; Tue, 28 Feb 2006 15:05:04 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- Received: from candle.pha.pa.us (candle.pha.pa.us [70.90.9.53]) by postgresql.org (Postfix) with ESMTP id 16D669DCAA8 for ; Tue, 28 Feb 2006 15:05:01 -0400 (AST) Received: (from pgman@localhost) by candle.pha.pa.us (8.11.6/8.11.6) id k1SJ52b19021; Tue, 28 Feb 2006 14:05:02 -0500 (EST) From: Bruce Momjian Message-ID: <200602281905.k1SJ52b19021@candle.pha.pa.us> Subject: Re: [BUGS] FATAL: semctl(1672698088, 12, SETVAL, 0) failed In-Reply-To: To: Qingqing Zhou Date: Tue, 28 Feb 2006 14:05:02 -0500 (EST) cc: pgsql-bugs@postgresql.org X-Mailer: ELM [version 2.4ME+ PL121 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.4 required=5 tests=[AWL=-0.100, RAZOR2_CHECK=0.5] X-Spam-Score: 0.4 X-Mailing-List: pgsql-bugs List-Archive: List-Help: List-Id: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: Precedence: bulk Sender: pgsql-bugs-owner@postgresql.org Status: RO Qingqing Zhou wrote: > I encountered an error when I fast shutdown 8.1.1 on Win2k: > > FATAL: semctl(1672698088, 12, SETVAL, 0) failed: A blocking operation > was interrupted by a call to WSACancelBlockingCall. > > A similar error on 8.1/win2003 was reported on pgsql-general (sorry, I can't > dig out the > original post from our web archives): > > From: Niederland > Date: Tues, Dec 13 2005 9:49 am > > 2005-12-12 20:30:00 FATAL: semctl(50884184, 15, SETVAL, 0) failed: A > non-blocking socket operation could not be completed immediately. > > --- > > There are two problems here: > > (1) Why a socket error? > 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. > (2) What's happened here? > It may come from PGSemaphoreReset(), and win32 semop() looks like this: > > ret = WaitForMultipleObjectsEx(2, wh, FALSE, (sops[0].sem_flg & > IPC_NOWAIT) ? 0 : INFINITE, TRUE); > ... > else if (ret == WAIT_OBJECT_0 + 1 || ret == WAIT_IO_COMPLETION) > { > pgwin32_dispatch_queued_signals(); > errno = EINTR; > } > else if (ret == WAIT_TIMEOUT) > errno = EAGAIN; > > So it seems the EINTR is caused by an incoming signal, the EAGAIN is caused > by a TIMEOUT ... any ideas? I looked at the documentation for the function: 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? -- 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. + ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq From pgsql-bugs-owner+M14483@postgresql.org Tue Feb 28 21:12:39 2006 Return-path: Received: from ams.hub.org (ams.hub.org [200.46.204.13]) by candle.pha.pa.us (8.11.6/8.11.6) with ESMTP id k212Cdk24423 for ; Tue, 28 Feb 2006 21:12:39 -0500 (EST) Received: from postgresql.org (postgresql.org [200.46.204.71]) by ams.hub.org (Postfix) with ESMTP id 2D9CF67B7CA for ; Tue, 28 Feb 2006 22:12:36 -0400 (AST) X-Original-To: pgsql-bugs-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by postgresql.org (Postfix) with ESMTP id D8B0B9DC837 for ; Tue, 28 Feb 2006 22:12:17 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 65124-06 for ; Tue, 28 Feb 2006 22:12:21 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- Received: from floppy.pyrenet.fr (news.pyrenet.fr [194.116.145.2]) by postgresql.org (Postfix) with ESMTP id 7C5729DC81D for ; Tue, 28 Feb 2006 22:12:15 -0400 (AST) Received: by floppy.pyrenet.fr (Postfix, from userid 106) id 6A8CA30BA5; Wed, 1 Mar 2006 03:12:19 +0100 (MET) From: "Qingqing Zhou" X-Newsgroups: pgsql.bugs Subject: Re: [BUGS] FATAL: semctl(1672698088, 12, SETVAL, 0) failed Date: Wed, 1 Mar 2006 10:08:58 +0800 Organization: Hub.Org Networking Services Lines: 68 Message-ID: References: <200602281905.k1SJ52b19021@candle.pha.pa.us> X-Complaints-To: usenet@news.hub.org X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1506 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 To: pgsql-bugs@postgresql.org X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.169 required=5 tests=[AWL=0.169] X-Spam-Score: 0.169 X-Mailing-List: pgsql-bugs List-Archive: List-Help: List-Id: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: Precedence: bulk Sender: pgsql-bugs-owner@postgresql.org Status: ROr "Bruce Momjian" 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. > > (2) What's happened here? > > It may come from PGSemaphoreReset(), and win32 semop() looks like this: > > > > ret = WaitForMultipleObjectsEx(2, wh, FALSE, (sops[0].sem_flg & > > IPC_NOWAIT) ? 0 : INFINITE, TRUE); > > ... > > else if (ret == WAIT_OBJECT_0 + 1 || ret == WAIT_IO_COMPLETION) > > { > > pgwin32_dispatch_queued_signals(); > > errno = EINTR; > > } > > else if (ret == WAIT_TIMEOUT) > > errno = EAGAIN; > > > > So it seems the EINTR is caused by an incoming signal, the EAGAIN is caused > > by a TIMEOUT ... any ideas? > > I looked at the documentation for the function: > > 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. Regards, Qingqing ---------------------------(end of broadcast)--------------------------- TIP 1: 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 From pgsql-bugs-owner+M14485@postgresql.org Tue Feb 28 22:08:57 2006 Return-path: Received: from ams.hub.org (ams.hub.org [200.46.204.13]) by candle.pha.pa.us (8.11.6/8.11.6) with ESMTP id k2138uk09057 for ; Tue, 28 Feb 2006 22:08:56 -0500 (EST) Received: from postgresql.org (postgresql.org [200.46.204.71]) by ams.hub.org (Postfix) with ESMTP id B4EFF67B7CA for ; Tue, 28 Feb 2006 23:08:53 -0400 (AST) X-Original-To: pgsql-bugs-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by postgresql.org (Postfix) with ESMTP id 4A2B39DCB5D for ; Tue, 28 Feb 2006 23:08:34 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 77300-07 for ; Tue, 28 Feb 2006 23:08:38 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- Received: from candle.pha.pa.us (candle.pha.pa.us [70.90.9.53]) by postgresql.org (Postfix) with ESMTP id E8B109DCB0D for ; Tue, 28 Feb 2006 23:08:31 -0400 (AST) Received: (from pgman@localhost) by candle.pha.pa.us (8.11.6/8.11.6) id k2138bO09022; Tue, 28 Feb 2006 22:08:37 -0500 (EST) From: Bruce Momjian Message-ID: <200603010308.k2138bO09022@candle.pha.pa.us> Subject: Re: [BUGS] FATAL: semctl(1672698088, 12, SETVAL, 0) failed In-Reply-To: To: Qingqing Zhou Date: Tue, 28 Feb 2006 22:08:37 -0500 (EST) cc: pgsql-bugs@postgresql.org X-Mailer: ELM [version 2.4ME+ PL121 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.404 required=5 tests=[AWL=-0.096, RAZOR2_CHECK=0.5] X-Spam-Score: 0.404 X-Mailing-List: pgsql-bugs List-Archive: List-Help: List-Id: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: Precedence: bulk Sender: pgsql-bugs-owner@postgresql.org Status: RO Qingqing Zhou wrote: > > "Bruce Momjian" 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. + ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster