Thread: backend freezeing on win32 fixed (I hope ;-) )
Hi, I think I have fixed the freezing of the postgres backend on Windows NT. Now it survives 5 regression test in a cycle with some concurrent connections during running the tests. Where the problem was (manual backtrace): - InitPostgres() (utils/init/postinit.c) - InitProcess() (storage/lmgr/proc.c) - IpcSemaphoreCreate() (storage/ipc/ipc.c) - semget() (now in libcygipc - sem.c) - sem_connect() (sem.c) - WaitForSingleObject() (win32 system call) - freezing.... It have looked like a problem with initializing the same semaphore for second time (they are "preinitialized" for performance reasons in InitProcGlobal() in storage/lmgr/proc.c) The fix (made for v6.5.1) is here: ------------------------------- --- src/backend/storage/lmgr/proc.c.old Sat Aug 14 16:50:19 1999 +++ src/backend/storage/lmgr/proc.c Sat Aug 14 16:50:52 1999 @@ -160,6 +160,7 @@ * Pre-create the semaphores for the first maxBackends processes, * unless we are running as a standalone backend. */ +#ifndef __CYGWIN__ if (key != PrivateIPCKey) { for (i = 0; @@ -180,6 +181,7 @@ ProcGlobal->freeSemMap[i] = (1 << PROC_NSEMS_PER_SET); } } +#endif /* __CYGWIN__ */ }} ------------------------------- Dan PS: I have packed the tree after "make install" for 6.5.1 with the patch above, so it is a "binary distribution". ---------------------------------------------- Daniel Horak network and system administrator e-mail: horak@mmp.plzen-city.cz privat e-mail: dan.horak@email.cz ICQ:36448176 ----------------------------------------------
Horak Daniel <horak@mmp.plzen-city.cz> writes: > I think I have fixed the freezing of the postgres backend on Windows NT. Now > it survives 5 regression test in a cycle with some concurrent connections > during running the tests. > It have looked like a problem with initializing the same semaphore for > second time (they are "preinitialized" for performance reasons in > InitProcGlobal() in storage/lmgr/proc.c) They should never be "initialized a second time". And the preallocation is *not* for performance reasons, it is to make sure we can actually get enough semaphores (rather than dying under load when we fail to get the N+1'st semaphore when starting the N+1'st backend). > The fix (made for v6.5.1) is here: > [ Fix consists of diking out preallocation of semaphores by postmaster ] I do not like this patch one bit --- I think it is voodoo that doesn't really have anything to do with the true problem. I don't know what the true problem is, mind you, but I don't think this is the way to fix it. Is it possible that the CygWin environment doesn't have a correct emulation of IPC semaphores, such that a sema allocated by one process (the postmaster) is not available to other procs (the backends)? That would explain preallocation not working --- but if that's it then we have major problems in other places, since the code assumes that a sema once allocated will remain available to later backends. regards, tom lane
On Mon, Aug 16, 1999 at 10:07:00AM -0400, Tom Lane wrote: >Is it possible that the CygWin environment doesn't have a correct >emulation of IPC semaphores, such that a sema allocated by one process >(the postmaster) is not available to other procs (the backends)? >That would explain preallocation not working --- but if that's it then >we have major problems in other places, since the code assumes that a >sema once allocated will remain available to later backends. We don't have correct emulation of IPC semapahores since they are not implemented at all. I assume that if you're relying on persistent semaphores, then some add-on package is being used. cgf