HaveNFreeProcs ?
Hackers,
I just noticed the HaveNFreeProcs routine is coded as a loop around the
ProcGlobal struct members. I wonder if it's possible to use a simple
check in procArray->numBackends against procArray->maxBackends instead?
--
Alvaro Herrera (<alvherre[a]surnet.cl>)
Jason Tesser: You might not have understood me or I am not understanding you.
Paul Thomas: It feels like we're 2 people divided by a common language...
Alvaro Herrera <alvherre@surnet.cl> writes:
I just noticed the HaveNFreeProcs routine is coded as a loop around the
ProcGlobal struct members. I wonder if it's possible to use a simple
check in procArray->numBackends against procArray->maxBackends instead?
It used to look like that, but now that numBackends includes prepared
transactions that's no longer a useful test. I think that the existing
coding is OK, because it's written to not loop more than
superuser_reserved_connections times, and it's hard to imagine anyone
would set that to more than half a dozen or so.
Also, that routine will disappear entirely if we agree to remove
commit_siblings (see nearby thread), so right at the moment I'm not very
concerned about improving it. If it is still there forty-eight hours
from now, let's talk about it then.
regards, tom lane
I wrote:
Also, that routine will disappear entirely if we agree to remove
commit_siblings (see nearby thread), so right at the moment I'm not very
concerned about improving it. If it is still there forty-eight hours
from now, let's talk about it then.
Oh, never mind that, I was momentarily confusing it with
CountActiveBackends. But the other point stands.
regards, tom lane
I wrote:
... because it's written to not loop more than
superuser_reserved_connections times, and it's hard to imagine anyone
would set that to more than half a dozen or so.
We could help keep people on the correct path if guc.c enforced a sane
upper limit on superuser_reserved_connections. I'm thinking somewhere
around 10.
Any thoughts about that?
regards, tom lane
On Thu, Jun 23, 2005 at 12:44:25AM -0400, Tom Lane wrote:
I wrote:
... because it's written to not loop more than
superuser_reserved_connections times, and it's hard to imagine anyone
would set that to more than half a dozen or so.We could help keep people on the correct path if guc.c enforced a sane
upper limit on superuser_reserved_connections. I'm thinking somewhere
around 10.Any thoughts about that?
Maybe a warning in the docs and the sample/default config file would be
better. It seems silly to limit this just because it might cause a
performance problem (this is just a performance issue, right?)
--
Jim C. Nasby, Database Consultant decibel@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828
Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"