Mike Mascari <mascarim@yahoo.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?
So I'm guessing a leak of allocated file descriptors.
After grovelling through the calls to AllocateFile, I only see one
prospect for a leak: it looks to me like verify_password() neglects
to close the password file if an invalid user name is given. Do you
use a plain (non-encrypted) password file? If so, I'll bet you can
reproduce the crash by trying repeatedly to connect with a username
that's not in the password file. If that pans out, it's a simple fix:
add "FreeFile(pw_file);" near the bottom of verify_password() in
src/backend/libpq/password.c. Let me know if this guess is right...
regards, tom lane
