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