Re: 8.2.3: Server crashes on Windows using Eclipse/Junit
От | Trevor Talbot |
---|---|
Тема | Re: 8.2.3: Server crashes on Windows using Eclipse/Junit |
Дата | |
Msg-id | 90bce5730710220743x47316dbq7ab61f2c632892bf@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: 8.2.3: Server crashes on Windows using Eclipse/Junit (Magnus Hagander <magnus@hagander.net>) |
Ответы |
Re: 8.2.3: Server crashes on Windows using Eclipse/Junit
|
Список | pgsql-general |
On 10/21/07, Magnus Hagander <magnus@hagander.net> wrote: > > 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... I'd probably take the approach of combining win32_waitpid() and threads. You'd end up with 1 thread per 64 backends; when something interesting happens the thread could push the info onto a queue, which the new win32_waitpid() would check. Use APCs to add new backends to threads with free slots.
В списке pgsql-general по дате отправления: