| From: | The Hermit Hacker <scrappy(at)hub(dot)org> |
|---|---|
| To: | "Robert D(dot) Nelson" <RDNELSON(at)co(dot)centre(dot)pa(dot)us> |
| Cc: | "Alexey V(dot)Borzov" <borz_off(at)rdw(dot)ru>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-general <pgsql-general(at)postgresql(dot)org> |
| Subject: | RE: WTF is going on with PG_VERSION? |
| Date: | 2000-09-20 14:37:26 |
| Message-ID: | Pine.BSF.4.21.0009201136080.17831-100000@thelab.hub.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Wed, 20 Sep 2000, Robert D. Nelson wrote:
> >I'm wondering if you could be running out of kernel filetable slots,
> >so that the open of PG_VERSION is failing with ENFILE. (This would be
>
> An interesting slashdot thread (that's saying alot, since I despise the
> place ;) yesterday mentioned putting cached stuff in RAM drives. Would that
> alleviate the problem, if one could load just the PG_VERSION's in there, or
> would it still need to allocate it when it was trying to read it? Don't
> think it's a real solution, merely curious :)
It still needs a file descritpor for each file opened ... for my system,
the default was somethign like 4k file descriptors, which I was blowing
away on a regular basis. I ended up finally settling on 32k file
descriptors and the problem hasn't resurfaced ... I wasn't getting a
PG_VERSION file problem, but that appears to be the direction Tom is
thinking right now ...
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Martin Gainty | 2000-09-20 15:00:17 | Re: Building Windows fat clients |
| Previous Message | Tom Lane | 2000-09-20 14:22:46 | Re: Proposal for new PL/Perl README |