> > 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/RAZ...trace_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 5: don't forget to increase your free space map settings

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/RAZ...trace_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

On Sun, Oct 02, 2005 at 12:20:05PM +0200, Thomas Hallgren wrote:
> I added some traces to the code. I know that the following happens when
> I start a postmaster.

<snip>

> 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);

Well, pgStatSock is the only SOCK_DGRAM socket, all the others are
SOCK_STREAM, maybe that's the difference? It's also connected to
itself, although for DGRAM sockets that's not that special.

The documentation isn't totally clear about this. Yet the error thrown
should terminate the process, yet it obviously isn't. Very odd.

Any Windows programmers with ideas?
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQFDP/jWIB7bNG8LQkwRAnbjAJ9ruwEUtEXezC6aWk8cQSBYgDTYyQCe LY0N
+7yW1KMZ2ajIeiCp0/COe04=
=+brw
-----END PGP SIGNATURE-----

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/RAZ...trace_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

Thomas Hallgren wrote:

> 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.

I guess the question is, why is a "DNS Provider" software blocking
socket creation? Is there a way we could work around that?

--
Alvaro Herrera Architect, http://www.EnterpriseDB.com
"El destino baraja y nosotros jugamos" (A. Schopenhauer)

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings