Francisco Olarte <folarte@peoplecall.com> writes:
> On Tue, Feb 13, 2018 at 4:50 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Putting two and two together, you have some monitoring program that is
>> hitting the postmaster with a constant stream of TCP connection requests
>> none of which get completed, resulting in a whole lot of useless fork
>> activity. Dial down the monitoring.
> Adding the incomplete startup to the mix, it may be a misconfigured
> monitoring program sending just a byte or two, or zero, and then
> waiting for response, which will give ps more time to catch the child
> in that state. Haven't look at the code, but given messages state with
> 1 identifier byte plus a 4 byte length, many of the forms of reading
> that would lead to a big wait for at least 5 bytes, or for the first
> byte.
Hm, yeah. From memory, the child process will wait a maximum of 60
seconds to receive a startup packet. If the hypothesized probing program
sends nothing, or just a small number of bytes, and then sits rather than
closing the connection, then this state would easily persist long enough
to be observable in ps.
If you're not sure where these probes are coming from, turning on
log_connections should help: the "connection received" message comes out
before waiting for the startup packet.
regards, tom lane