Re: [HACKERS] Postmaster dies with FATAL 1: ReleaseLruFile: No opened files - no one can be closed
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] Postmaster dies with FATAL 1: ReleaseLruFile: No opened files - no one can be closed |
Дата | |
Msg-id | 12268.942621824@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Postmaster dies with FATAL 1: ReleaseLruFile: No opened files - no one can be closed (Mike Mascari <mascarim@yahoo.com>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: