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(¶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
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
