Trevor Talbot wrote:
> On 10/17/07, Magnus Hagander <magnus@xxxxxxxxxxxx> wrote:
>> On Wed, Oct 17, 2007 at 02:40:14AM -0400, Tom Lane wrote:
>
>>> Maybe we should put an #ifdef WIN32 into guc.c to limit max_connections
>>> to something we know the platform can stand? It'd be more comfortable
>>> if we understood exactly where the limit was, but I think I'd rather
>>> have an "I'm sorry Dave, I can't do that" than random-seeming crashes.
>> Yeayh, that's probably a good idea - except we never managed to figure out
>> where the limit is. It appears to vary pretty wildly between different
>> machines, for reasons we don't really know why (total RAM has some effect
>> on it, but that's not the only one, for example)
>
> I tried generating idle connections in an effort to reproduce
> Laurent's problem, but I ran into a local limit instead: for each
> backend, postmaster creates a thread and burns 4MB of its 2GB address
> space. It fails around 490.
Oh, that's interesting. That's actually a sideeffect of us increasing
the stack size for the postgres.exe executable in order to work on other
things. By default, it burns 1MB/thread, but ours will do 4MB. Never
really thought of the problem that it'll run out of address space.
Unfortunately, that size can't be changed in the CreateThread() call -
only the initially committed size can be changed there.
There are two ways to get around it - one is not using a thread for each
backend, but a single thread that handles them all and then some sync
objects around it. We originally considered this but said we won't
bother changing it because the current way is simpler, and the overhead
of a thread is tiny compared to a process. I don't think anybody even
thought about the fact that it'd run you out of address space...
The other way is to finish off win64 support :-) Which I plan to look
at, but I don't think that alone should be considered a solution.
The question is if it's worth fixing that part, if it will just fall
down for other reasons before we reach these 500 connections anyway. Can
you try having your program actually run some queries and so, and not
just do a PQconnect? To see if it falls over then, because it's been
doing more?
> Laurent's issue must depend on other load characteristics. It's
> possible to get a trace of DLL loads, but I haven't found a
> noninvasive way of doing that. It seems to require a debugger be
> attached.
AFAIK, it does require that, yes.
//Magnus
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
