Re: [HACKERS] File descriptor leakage?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp>
Cc: "Vadim Mikheev" <vadim(at)krs(dot)ru>, "Cyrus Rahman" <cr(at)photox(dot)jcmax(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [HACKERS] File descriptor leakage?
Date: 1999-09-01 13:41:14
Message-ID: 17671.936193274@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp> writes:
>> Tom Lane wrote:
>>>> Interestingly, this isn't a big problem on platforms where there is
>>>> a relatively low limit on number of open files per process.

> It's not a small problem on platforms such as cygwin, OS2 where we
> couldn't unlink open files.

Ah, right, good ol' microsoft strikes again...

> We have to close useless file descriptors ASAP there.
> 6.5.2-release should be stable as possible.
> So I don't object to the riskless way as Vadim mentioned.

Well, Vadim's "riskless solution" does NOT solve the problem you mention
above, AFAICT. Reducing the number of kernel file descriptors won't
magically cause forgotten descriptors for a table you want to delete
to not be there --- it just shortens the interval where you'll have a
problem, by shortening the interval before the descriptors get recycled.
If you reduce the number of descriptors enough to make the problem
unlikely to occur, you'll be taking a big performance hit.

So we need a proper fix to ensure the relation code doesn't forget about
open descriptors.

I will try to take a look at Hiroshi's patch this evening, and will
commit it to both branches if I can't find anything wrong with it...

regards, tom lane

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 1999-09-01 13:55:14 Re: [HACKERS] Postgres' lexer
Previous Message Tom Lane 1999-09-01 13:30:38 Re: [HACKERS] SELECT BUG