HaveNFreeProcs ?

Started by Alvaro Herreraover 20 years ago5 messages
#1Alvaro Herrera
alvherre@surnet.cl

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...

#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: Alvaro Herrera (#1)
Re: HaveNFreeProcs ?

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

#3Tom Lane
tgl@sss.pgh.pa.us
In reply to: Tom Lane (#2)
Re: HaveNFreeProcs ?

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

#4Tom Lane
tgl@sss.pgh.pa.us
In reply to: Tom Lane (#2)
Re: HaveNFreeProcs ?

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

#5Jim C. Nasby
decibel@decibel.org
In reply to: Tom Lane (#4)
Re: HaveNFreeProcs ?

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?"