Re: [HACKERS] DROP TABLE leaks file descriptors

Started by Bruce Momjianalmost 27 years ago4 messageshackers

bruce@momjian.us

almost 27 years ago

Tom, is this resolved?

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...

regards, tom lane

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Import Notes

Reply to msg id not found: 28813.923260329@sss.pgh.pa.us

Tom Lane

tgl@sss.pgh.pa.us

almost 27 years ago

In reply to: Bruce Momjian (#1)

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

Show quoted text

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...

Import Notes

Reply to msg id not found: YourmessageofMon10May1999110102-0400199905101501.LAA02414@candle.pha.pa.us | Resolved by subject fallback

Tom Lane

tgl@sss.pgh.pa.us

almost 27 years ago

In reply to: Tom Lane (#2)

Bruce Momjian <maillist@candle.pha.pa.us> writes:

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.

AFAIC the patch by Ole Gjerde [gjerde@icebox.org] which has already
been appiled by Bruce Momjan would solve this problem.

I thought that patch was just for multi-segment tables, which does not
fix the original problem.

But didn't Ole replace a call to FileNameUnlink with a call to mdunlink
(or some other higher level routine)? If mdunlink also closes the VFD
for the index, then that patch might indeed have fixed it. I'll try
the test case I had, and report back.

regards, tom lane

Import Notes

Reply to msg id not found: YourmessageofMon17May1999002602-0400199905170426.AAA24747@candle.pha.pa.us | Resolved by subject fallback

Tom Lane

tgl@sss.pgh.pa.us

almost 27 years ago

In reply to: Tom Lane (#3)

"Hiroshi Inoue" <Inoue@tpf.co.jp> writes:

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.

AFAIC the patch by Ole Gjerde [gjerde@icebox.org] which has already
been appiled by Bruce Momjan would solve this problem.
Would you please ascertain the fact ?

You are correct: I find that repeatedly creating and dropping a table
with an index does not leak file descriptors (either real or virtual)
as of yesterday's sources. So this item can be removed from TODO.

regards, tom lane

Import Notes

Reply to msg id not found: YourmessageofMon17May1999131521+0900000b01bea01be12df8402801007e@cadzone.tpf.co.jp | Resolved by subject fallback