[pgpool-general: 2174] Re: read_startup_packet: incorrect packet length What does that mean?
ishii at postgresql.org
Tue Oct 8 15:14:31 JST 2013
> Hi Tatsuo,
>> Hi Michal,
>>> Hi Tatsuo.
>>> Sorry for the delayed answer.
>>> In the meantime I've changed the configuration, but the message
>>> "read_startup_packet: incorrect packet length" didn't go away. I am
>>> attaching configuration at the end of the e-mail and also a log file
>>> right after I started Pgpool.
>>> I think I understand the issue I've described in the last e-mail. I
>>> mean the psql -c "show pool_nodes;" -d postgres -U postgres -p 9898 ->
>>> the port should be 9999. Just silly typo.
>>> I would like to summary of the issues I am experiencing now:
>>> 1. There are periodic ERROR messages in the Pgpool log file -
>>> "read_startup_packet: incorrect packet length (-1656006549)".
>>> 2. There are periodic messages in the PostgreSQL log file -
>>> "incomplete startup packet".
>>> 3. If I halt or reboot primary node (soft shutdown), the secondary
>>> node triggers fail-over immediatelly. --> NOT DESIRED BEHAVIOUR 4. If
>>> I power off the primary node (unexpectedly), the secondary node
>>> applies health_check and triggers fail-over after health_check
>>> time-out. --> DESIRED BEHAVIOUR
>>> I think, the first two issues are related. But don't know what could
> cause it.
>>> We are using special services which connects to the Pgpool by using
>>> JDBC. Can the services be the source of these error messages?
>>No idea. However, you can enable "log_connections" which logs who is
> connecting to pgpool. This will reveal who is the client when the errors
> Good point. I will try to investigate it and also asks our developers what
> could do that. From what I know the services are doing the "SELECT 1" query
> to determine if the backend is alive. But that is a normal thing. We'll see.
>>> According to issue number 3.. I can see in the log file, what happened:
>>> "postmaster on DB node 0 was shutdown by administrative command".
>>> How can I force Pgpool to not fail-over after the administrative
>>> command was issued? I would like to apply same health_check timouts
>>> also in the situation when the administrative command was issued. It
>>> is because in our environment one node is represented by more hosts
>>> where the Postgresql services are migrating from one host to another
> automatically. It occurs also if the "halt"
>>> or "reboot" command is issued on that one node. This is not errorneous
>>> condition for our environment, because if the "halt" is issued on one
>>> host, PostgreSQL service will be brought up on another node. Virtual
>>> IP address is in front of it.
>>I understand your situation. What you can do is setting:
>>backend_flag0 = 'DISALLOW_TO_FAILOVER'
>>This will prevent your primary node from fail-over by "shutdown by
> administrative command". Please note that this will also prevent the primary
> from fail-over by the health check.
> This is what I was hoping to avoid. Because it will absolutly disallow to
> fail-over from primary node to the secondary. But thank you anyway. I am now
> certain that, there is no other way and I should include additional steps to
> maintenance manual, which should be taken in the process of restarting one
> host by administrative command where pgpool currently runs.
> One more question.. do you plan to add the setting of "not to fail-over by
> administrative command" in the future releases or it is absolutely wrong
IMO, that would be a good idea. I will add it to the TODO list.
SRA OSS, Inc. Japan
More information about the pgpool-general