On 12/2/16 12:52 PM, Tom Lane wrote:
I think you misread it. Note the "n > 0" part of the while condition.
*facepalm*
Sorry for the noise...
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in
Jim Nasby writes:
> Current HaveNFreeProcs() iterates through the entire freeProcs list
> (while holding ProcStructLock) just to determine if there's a small
> number (superuser_reserved_connections) of free slots available.
I think you misread it. Note the "n > 0"
Current HaveNFreeProcs() iterates through the entire freeProcs list
(while holding ProcStructLock) just to determine if there's a small
number (superuser_reserved_connections) of free slots available. For the
common case, presumably it'd be faster to put the n<=0 test inside the
loop and
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
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
Alvaro Herrera [EMAIL PROTECTED] 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
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
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.