Magnus Hagander <[EMAIL PROTECTED]> writes:
> We're not talking about the backends, we're talking about the backend
> waiter threads whose sole purpose is to wait for a backend to die and
> then raise a signal when it does.
Oh, OK, I had not twigged to exactly what the threads were being used
for.
On 10/22/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
> > I was planning to make it even easier and let Windows do the job for us,
> > just using RegisterWaitForSingleObject(). Does the same - one thread per
> > 64 backends, but we don't have to deal with th
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
>> I was planning to make it even easier and let Windows do the job for us,
>> just using RegisterWaitForSingleObject(). Does the same - one thread per
>> 64 backends, but we don't have to deal with the queueing ourselves.
>> Should be r
Magnus Hagander <[EMAIL PROTECTED]> writes:
> I was planning to make it even easier and let Windows do the job for us,
> just using RegisterWaitForSingleObject(). Does the same - one thread per
> 64 backends, but we don't have to deal with the queueing ourselves.
> Should be rather trivial to do.
* Magnus Hagander:
> 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
Florian Weimer wrote:
> * Magnus Hagander:
>
>> 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
