On Thu, 21 Sep 2000, Alexey Borzov wrote:
> Greetings, Tom!
>
> At 20.09.2000, 10:41, you wrote:
>
> TL> "Alexey V. Borzov" <borz_off@rdw.ru> writes:
> >> Nope, that's not the problem. I just checked and every DB has its own
> >> PG_VERSION. Besides, _all_ of the databases are accessed on regular
> >> basis (I'm speaking of a website), but the crashes occur only once in
> >> a while (like, once a week)...
> TL> I'm wondering if you could be running out of kernel filetable slots,
> TL> so that the open of PG_VERSION is failing with ENFILE. (This would be
> TL> the trouble spot just because it's the first file a new backend tries
> TL> to open, and being a new backend it has no possible recovery tactic
> TL> like closing other files. Once a backend is up and running it can
> TL> usually survive ENFILE open failures by closing off other files.)
>
> This MIGHT be problem. I'm not sure, as it wasn't me who compiled
> the kernel for the box, but I'll look into it...
>
> Well, last question then: I wasn't too specific, but the problem
> with this crash is that not ONE SINGLE backend fails, but ALL OF
> THEM AT ONCE: someone comes running to me and shouts 'our site is
> down!', when I login and type 'ps eax | grep postgres' there
> are no postgres processes in memory... Which is strange, as I
> connect to Postgres from PHP, and use `persistent` connections, so
> the backends which are in memory should have already read their
> PG_VERSIONs...
> Is it as it should be with ENFILE failure?
that is as it was when we were hitting it ... we are actually running a db
on 4 seperate ports, and we would see one db beign down and the rest
running happily along ... as soon as one db goes for that last slot and
can't find it, that one would completely shut down, as its the 'parent
process' that appears to be the one going for it ...
