Re: Re: Too many open files (was Re: spinlock problems reported earlier) - Mailing list pgsql-hackers

From Brook Milligan
Subject Re: Re: Too many open files (was Re: spinlock problems reported earlier)
Date
Msg-id 200008281524.JAA08118@biology.nmsu.edu
Whole thread Raw
In response to Re: Too many open files (was Re: spinlock problems reported earlier)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Re: Too many open files (was Re: spinlock problems reported earlier)
List pgsql-hackers
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
availableusing 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
returnedvalue 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


pgsql-hackers by date:

Previous
From: Brook Milligan
Date:
Subject: Re: when does CREATE VIEW not create a view?
Next
From: Thomas Lockhart
Date:
Subject: Re: SQL COPY syntax extension (was: Performance on inserts)