"Hiroshi Inoue" <Inoue@tpf.co.jp> writes:
> vacuum calls open() directly to create pg_vlock file.
> Sometimes I was not able to open the file because of the lack of
> file descriptors().
> FileNameOpenFile()/FileClose() etc should be called instead of
> open()/close() etc ?
That is a good point, but actually I think it should not be a problem.
vacuum.c just does open() and immediately close() on pg_vlock; it
doesn't hold the file descriptor open.
When I fixed psort.c a few weeks ago, I looked through all the other
direct calls of open() and fopen() in the backend. There are still half
a dozen or so, but none of them open more than one file or will hold the
file descriptor for longer than the execution of the function they're
in. So I felt it was OK to leave them alone.
The reason it's OK is that fd.c doesn't use up all the available
file descriptors --- it tries to leave ten or so unused. That's
necessary to ensure that library functions like dlopen() will work,
because they don't know anything about using fd.c's routines.
So, the occasional short-term file opening in vacuum.c and similar
places should not matter. If those do fail for lack of FDs, then the
*real* problem is that fd.c is not estimating correctly how many file
descriptors it can safely use; that's what we need to fix.
But what I want to know right now is whether this behavior has been
seen with code from the last week or two. Maybe the report is just
a side-effect of the FD leaks that used to exist in several places...
regards, tom lane