Larry Rosenman wrote:
I had to hack on the code some more for FreeBSD:
(the realloc call needed the multiplication). I ran this same code
on UnixWare.
I feel like a moron, having missed that. Probably explains the bad
file number error I was getting on AIX, too...
--
Kevin Brown
Tom Lane wrote:
However, it seems that the real problem here is that we are so far off
base about how many files we can open. I wonder whether we should stop
relying on sysconf() and instead try to make some direct probe of the
number of files we can open. I'm imagining repeatedly open()
[EMAIL PROTECTED] (Tom Lane) wrote in message (in part)
...
Hmm. This may be OS-specific. The shlibs certainly show up in the
output of lsof in every variant I've checked, but do they count against
your open-file limit?
From the lsof FAQ:
5.2 Why doesn't Apple Darwin lsof report text
--On Sunday, February 22, 2004 23:00:31 -0500 Tom Lane [EMAIL PROTECTED]
wrote:
Kevin Brown [EMAIL PROTECTED] writes:
I wasn't able to test on HP-UX
I get the same result on HPUX, after whacking the test program around
a bit: no change in the number of files we can open. Confirmations on
I wrote:
Larry Rosenman wrote:
I had to hack on the code some more for FreeBSD:
(the realloc call needed the multiplication). I ran this same code
on UnixWare.
I feel like a moron, having missed that. Probably explains the bad
file number error I was getting on AIX, too...
And sure
On Slackware 8.1:
[EMAIL PROTECTED]:~/src$ ./eatallfds libm.so libtcl.so libjpeg.so
dup() failed: Too many open files
Was able to use 1021 file descriptors
dup() failed: Too many open files
Was able to use 1021 file descriptors after opening 3 shared libs
On OpenBSD 3.1:
grayling# ./eatallfds
--On Monday, February 23, 2004 04:52:09 -0800 Kevin Brown
[EMAIL PROTECTED] wrote:
Larry Rosenman wrote:
I had to hack on the code some more for FreeBSD:
(the realloc call needed the multiplication). I ran this same code
on UnixWare.
I feel like a moron, having missed that. Probably explains
Kevin Brown [EMAIL PROTECTED] writes:
Tom Lane wrote:
However, it seems that the real problem here is that we are so far off
base about how many files we can open. I wonder whether we should stop
relying on sysconf() and instead try to make some direct probe of the
number of files we can
Tom Lane wrote:
Kevin Brown [EMAIL PROTECTED] writes:
I originally thought that each shared library that was loaded would eat
a file descriptor (since I thought it would be implemented via mmap())
but that doesn't seem to be the case, at least under Linux
Hmm. This may be OS-specific.
Kevin Brown [EMAIL PROTECTED] writes:
Tom Lane wrote:
Hmm. This may be OS-specific. The shlibs certainly show up in the
output of lsof in every variant I've checked, but do they count against
your open-file limit?
It seems not, for both shared libraries that are linked in at startup
time
Kevin Brown [EMAIL PROTECTED] writes:
I wasn't able to test on HP-UX
I get the same result on HPUX, after whacking the test program around
a bit: no change in the number of files we can open. Confirmations on
other platforms please, anyone?
For anyone else who has problems getting it to
Attached is the test program I used.
Can folks please try this on other platforms?
[after some minor changes] Can confirm that LoadLibrary (aka dlopen) does
not reduce the files limit under Win32.
Cheers,
Claudio
---
Certain disclaimers and policies apply to all email sent from
Tom Lane wrote:
Confirmations on other platforms please, anyone?
For anyone else who has problems getting it to compile, try copying
the relevant version of pg_dlopen from src/backend/port/dynloader/. I
attach the code I actually ran on HPUX.
FWIW:
RH9
---
# ./eatallfds
I've looked into Olivier Hubaut's recent reports of 'Too many open
files' errors on OS X. What I find is that on Darwin, where we are
using Posix semaphores rather than SysV semaphores, each Posix semaphore
is treated as an open file --- it shows up in lsof output, and more to
the point it
14 matches
Mail list logo
