Re: Re[4]: WTF is going on with PG_VERSION?

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

In response to

Responses

Browse pgsql-general by date

  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?