With great help from Magnus, who advised me to use lspfix from cexx.org to list my lsp's, I found that I had gapsp.dll, "Neoteris DNS Provider" installed. An uninstall of the Neoteris software made this problem go away.

Regards,
Thomas Hallgren

Thomas Hallgren wrote:
I added some traces to the code. I know that the following happens when I start a postmaster.

StartupDatabase will call internal_fork_exec, it calls write_inheritable_socket 4 times and succeeds.

During the first iteration of ServerLoop:
 StartBackgroundWriter will call internal_fork_exec and succeed.
 pgstat_forkexec will call internal_fork_exec and succeed.

In the second iteration of ServerLoop, pgstat_forkexec will again call will call internal_fork_exec. This time it fails.
According to the log it fails on line:

   write_inheritable_socket(&param->pgStatSock, pgStatSock, childPid);

i.e. on it's second call to write_inheriable_socket. The failure is in a postgres.exe process, not postmaster.exe (and that's why I can't debug propery on Windoz).

Hope this helps.

Regards,
Thomas Hallgren


Magnus Hagander wrote:

If it's two zombies per minute, then I bet it's the stat
collector and
stat bufferer. They are restarted by the postmaster if not
found to
be running.
That would make some sense, because the stat processes need to set up new sockets (for the pipe between them). The autovacuum theory didn't hold any water in my eyes because autovacuum doesn't create any new sockets.

However, why two zombies? That would mean that the grandchild process started, which should mean that the pipe was already created ...

Does Windows have any equivalent of strace whereby we could watch what's happening during stats process launch?


First of all, I won't be able to dig into this any more until next week
- sorry about that. But others are always free to :-)

There is no strace equivalent builtin, but you can get an addon from
http://www.bindview.com/Services/RAZOR/Utilities/Windows/strace_readme.c
fm. Don't put it on a production box permanently, though, it tends to
cause BSODs in some cases.

//Magnus





---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

              http://www.postgresql.org/docs/faq

Reply via email to