Re: MacOS X Shared Buffers (SHMMAX)? - Mailing list pgsql-general

From Nigel J. Andrews
Subject Re: MacOS X Shared Buffers (SHMMAX)?
Date
Msg-id Pine.LNX.4.21.0205231506380.12663-100000@ponder.fairway2k.co.uk
Whole thread Raw
In response to Re: MacOS X Shared Buffers (SHMMAX)?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: MacOS X Shared Buffers (SHMMAX)?
List pgsql-general
On Wed, 22 May 2002, Tom Lane wrote:

> "Command Prompt, Inc." <pgsql-general@commandprompt.com> writes:
> > I was able to pull down the source for the Kernel, and increased the
> > SHMMAX by a factor of 16. Upgraded to the new Kernel and I am now able to
> > get safely 512 connections, even up around 900, but bumping it up to 1024,
> > I run into the following error:
>
> > PGSTATBUFF: recvfrom(2): Resource temporarily unavailable
> > DEBUG:  statistics collector process (pid 1988) exited with exit code 1
>
> > ...which then repeats itself infinitely until the calling process is
> > stopped. ;)
>
> [ scratches head... ] "Resource temporarily unavailable" is EAGAIN
> according to /usr/include/sys/errno.h on my OSX machine.  But the man
> page for recvfrom doesn't mention any plausible reasons for EAGAIN to
> be signaled.  select() just told us there was data available on the
> socket, so WTF?  Could this be a kernel bug?
>
> You could try modifying pgstat.c to continue its loop rather than
> exiting after it gets a recvfrom error.  But if the error condition
> recurs that'll just put pgstat.c into an infinite loop, so I'm not
> sure this is any solution --- just a way of gathering more data.

My 'standard' way of doing this is to loop while the error is EAGAIN but with a
small retry counter to limit the number of attempts made. Hopefully the second
time through the call isn't interrupted again. Therefore I'm usually quite
happy saying that after something like 5 calls to a routine then there really
is an error.

Isn't this how people normally handle this?

--
Nigel J. Andrews
Director

---
Logictree Systems Limited
Computer Consultants


pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: Violation of NOT NULL
Next
From: Tom Lane
Date:
Subject: Re: problems with pg_dump... with postmaster really