From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Alexey V(dot) Borzov" <borz_off(at)rdw(dot)ru> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Re[4]: WTF is going on with PG_VERSION? |
Date: | 2000-09-19 20:13:04 |
Message-ID: | 10879.969394384@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
"Alexey V. Borzov" <borz_off(at)rdw(dot)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)...
Does anything else get flaky on that system at the same times?
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
the trouble spot just because it's the first file a new backend tries
to open, and being a new backend it has no possible recovery tactic
like closing other files. Once a backend is up and running it can
usually survive ENFILE open failures by closing off other files.)
Being out of kernel filetable slots would usually cause a lot of
unrelated programs to start having troubles too, though, so I'd think
you'd be seeing other symptoms as well.
If that's it, the solution is either to alter your kernel parameters to
increase NFILE, or to reduce the allowed number of concurrent backends,
or both.
If you're not sure, you could modify the failing code (it's in
ValidatePgVersion() in src/utils/version.c) to print the kernel errno
value as part of the error message.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2000-09-19 20:38:02 | Re: nasty problem with redhat 6.2 + pg 7.02 |
Previous Message | Alexey V. Borzov | 2000-09-19 19:56:44 | Re[4]: WTF is going on with PG_VERSION? |