From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: Re: Too many open files (was Re: spinlock problems reported earlier) |
Date: | 2000-12-23 23:12:53 |
Message-ID: | 27090.977613173@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> Tom Lane writes:
>> I'm not sure why this didn't get dealt with, but I think it's a "must
>> fix" kind of problem for 7.1. The dbadmin has *got* to be able to
>> limit Postgres' appetite for open file descriptors.
> Use ulimit.
Even if ulimit exists and is able to control that parameter on a given
platform (highly unportable assumptions), it's not really a workable
answer. fd.c has to stop short of using up all of the actual nfile
limit, or else stuff like the dynamic loader is likely to fail.
> I think this is an unreasonable interference with the customary operating
> system interfaces (e.g., ulimit). The last thing I want to hear is
> "Postgres is slow and it only opens 100 files per process even though I
> <did something> to allow 32 million."
(1) A dbadmin who hasn't read the run-time configuration doc page (that
you did such a nice job with) is going to have lots of performance
issues besides this one.
(2) The last thing *I* want to hear is stories of a default Postgres
installation causing system-wide instability. But if we don't insert
an open-files limit that's tighter than the "customary operating system
limit", that's exactly the situation we have, at least on several
popular platforms.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2000-12-23 23:42:24 | Re: Re: Too many open files (was Re: spinlock problems reported earlier) |
Previous Message | Peter Eisentraut | 2000-12-23 23:06:29 | Re: Re: Too many open files (was Re: spinlock problems reported earlier) |