Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 28 Aug 2000 09:24:00 -0600 (MDT)
From:      Brook Milligan <brook@biology.nmsu.edu>
To:        tgl@sss.pgh.pa.us
Cc:        scrappy@hub.org, freebsd-hackers@freebsd.org, pgsql-hackers@postgreSQL.org
Subject:   Re: [HACKERS] Re: Too many open files (was Re: spinlock problems reported earlier)
Message-ID:  <200008281524.JAA08118@biology.nmsu.edu>
In-Reply-To: <7481.967438652@sss.pgh.pa.us> (message from Tom Lane on Mon, 28 Aug 2000 00:57:32 -0400)
References:  <Pine.BSF.4.21.0008272025160.717-100000@thelab.hub.org> <7481.967438652@sss.pgh.pa.us>

next in thread | previous in thread | raw e-mail | index | archive | help
   The Hermit Hacker <scrappy@hub.org> writes:
   > Okay, I just checked out Solaris 8/x86, and it confirms what HP/ux thinks:
   >      _SC_OPEN_MAX            OPEN_MAX                   Max open files per
   >                                                         process
   > I'm curious as to whether FreeBSD is the only one that doesn't follow this
   > "convention"?

From part of the NetBSD manpage for sysconf(3):

DESCRIPTION
     This interface is defined by IEEE Std1003.1-1988 (``POSIX'').  A far more
     complete interface is available using sysctl(3).

     _SC_OPEN_MAX
             The maximum number of open files per user id.

     _SC_STREAM_MAX
             The minimum maximum number of streams that a process may have
             open at any one time.

BUGS
     The value for _SC_STREAM_MAX is a minimum maximum, and required to be the
     same as ANSI C's FOPEN_MAX, so the returned value is a ridiculously small
     and misleading number.

STANDARDS
     The sysconf() function conforms to IEEE Std1003.1-1990 (``POSIX'').

HISTORY
     The sysconf function first appeared in 4.4BSD.

This suggests that _SC_STREAM_MAX might be a better value to use.  On
one of my NetBSD boxes I have the following:

_SC_OPEN_MAX:  64
_SC_STREAM_MAX:  20

In any case, if this really follows the POSIX standard, perhaps
PostgreSQL code should assume these semantics and work around other
cases that don't follow the standard (instead of work around the POSIX
cases).

Cheers,
Brook


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200008281524.JAA08118>