Re: [HACKERS] Postmaster dies with FATAL 1: ReleaseLruFile: No opened files - no one can be closed

--- Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Mike Mascari <mascarim(at)yahoo(dot)com> writes:
> > FATAL 1: ReleaseLruFile: No opened files - no one can be closed
>
> > This is the first time this has ever happened.
>
> I've never seen that either. Offhand I do not recall any post-6.5
> changes that would affect it, so the problem (whatever it is) is
> probably still there.
>
> After eyeballing the code, it seems there are only two ways this
> could happen:
>
> 1. the number of "allocated" (non-virtual) file descriptors grew to
> exceed the number of files Postgres thinks it can have open;
>
> 2. something else was temporarily exhausting your kernel's file table
> space, so that ENFILE was returned for many successive attempts to
> open a file. (After each one, fd.c will close another file and try
> again.)
>
> #2 seems improbable on an unloaded system, and isn't real probable even
> on a loaded one, since you'd have to assume that some other process
> managed to suck up each filetable slot that fd.c released before fd.c
> could re-acquire it. Once, yes, but several dozen times in a row?
>

Thanks for the response, Tom. When looking at the system log,
the kernel was logging messages regarding IPX network name collisions
which apprently can happen when there are autoconfigured Win95 boxes
on the same subnet. These messages were flooding the log at a rate of
one every second or two...Even though #2 seems improbable, and just
glancing at the IPX kernel code didn't point to how that may have
caused a continual consumption of file descriptors, I'm willing to
blame the kernel on this (and me for using autoprimary and autointerface
options).

Thanks again,

Mike Mascari
(mascarim(at)yahoo(dot)com)

=====

__________________________________________________
Do You Yahoo!?
Bid and sell for free at http://auctions.yahoo.com