On Tue, Feb 13, 2018 at 4:50 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Laurenz Albe <laurenz.albe@cybertec.at> writes:
>> Vikas Sharma wrote:
>>> On the master I can see multiple postmaster processes from the same data directory.
>>> ps -ef |grep -i postgres|grep postm
>>> postgres 81440 1 0 Jan31 ? 00:11:37 /usr/pgsql-9.4/bin/postmaster -D /var/lib/pgsql/9.4/data
>>> postgres 97072 81440 0 12:17 ? 00:00:00 /usr/pgsql-9.4/bin/postmaster -D /var/lib/pgsql/9.4/data
>>> postgres 97074 81440 0 12:17 ? 00:00:00 /usr/pgsql-9.4/bin/postmaster -D /var/lib/pgsql/9.4/data
>
>> The two other processes are children of the postmaster.
>> It is strange that their process title did not get updated.
>
> Seeing that they're showing zero runtime, I bet that these are just-forked
> children that have not had time to change their process title yet.
> The thing that is strange is that you have a steady enough flow of new
> connections that there are usually some children like that.
I assume proc title is changed after full startup, as it shows db and user....
>> The "incomplete startup packet" is caused by processes that connect to the
>> PostgreSQL TCP port, but don't complete a database connection.
>> Often these are monitoring or load balancing programs.
>
> 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.
Francisco Olarte.
