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_forkexecwill 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(¶m->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
>
>
