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

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?

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