Bruce Momjian <maillist@candle.pha.pa.us> writes:
> Tom, is this resolved?
It is not. The most visible symptom is masked as of last weekend:
since psort.c now uses virtual file descriptors rather than direct stdio
calls, the backend will not coredump for lack of file descriptors in
CREATE INDEX. But it is still true that DROP TABLE leaves a virtual
file descriptor open for each index on the dropped table, and that's
a bug in my book.
I don't know much about table creation/destruction, so was hoping to
get someone else to look at it.
regards, tom lane
>> I have just finished characterizing a nasty little bug in table
>> destruction. Do this:
>> create table x (i int4);
>> create index xindex on x (i);
>> drop table x;
>> The backend will now have one more open file than it had before
>> (use lsof or similar tool to check). Repeat enough times, and
>> the backend crashes for lack of file descriptors.
>>
>> It appears that the file that is left open is the index relation.
>> The index is *not* open at the end of the CREATE INDEX command;
>> apparently, DROP TABLE opens the index for some reason, and then
>> forgets to close the file descriptor when it destroys the index.
>>
>> Create more than one index, and they're *all* held open after DROP.
>>
>> I see the same behavior in both 6.4.2 and 6.5-current.
>>
>> Does anyone have a good idea where to look for the resource leak?
>> I've never looked at table creation/destruction...