[pgpool-hackers: 4158] Re: Should we downgrade logging level "ERROR: unable to read data ... child connection forced to terminate due to client_idle_limit:%d is reached"?

[Tatsuo Ishii]

> On Mon, 9 May 2022 12:19:44 +0900
> Bo Peng <pengbo at sraoss.co.jp> wrote:
> 
>> If we set "client_idle_limit" to a non-zero value, the connection
>> will be disconnected if it remains idle since the last query.
>>
>> The disconnection is caused by Pgpool-II settings,
>> but Pgpool-II handles the log message as an "ERROR".
>>
>> -------------
>> psql pid 2419: ERROR:  unable to read data
>> psql pid 2419: DETAIL:  child connection forced to terminate due to
>> client_idle_limit:30 is reached -------------
>>
>> Although it is harmless, it can sometimes confuse users.
>> Should we downgrade the logging level?
>>
>> In the source code, FRONTEND_ERROR is used.
>> FRONTEND_ERROR sets the logging level to ERROR and disconnect
>> the cached connections between Pgpool-II and PostgreSQL.
>> If we downgrade the message, I think we need to define a new macro.
>> Any comments?
>>
>> ---------------
>> if (idle_count > pool_config->client_idle_limit)
>> {
>>     ereport(FRONTEND_ERROR,
>>             (pool_error_code("57000"),
>>              errmsg("unable to read data"),
>>              errdetail("child connection forced to terminate due to
>> client_idle_limit:%d is reached", pool_config->client_idle_limit)));
>> }
>>
>>
>> /*
>>  * Check some cases in which we want to promote an error into a more
>>  * severe error.  None of this logic applies for non-error messages.
>>  */
>> if (elevel == FRONTEND_ERROR)
>> {
>>     frontend_invalid = true;
>>     elevel = ERROR;
>> }
>> ---------------
>>
> 
> Hi,
> 
> Personally I'd like it if that one was downgraded. I can't imagine a
> situation where a client disconnect(for whatever reason) should be
> regarded as an ERROR server-side. We get plenty of false positives in
> logging systems already(from a lot of different services), and getting
> rid of just one would be nice :)

PostgreSQL has similar parameter called idle_session_timeout.  If
client does not send any new query within idle_session_timeout, the
client will get:

FATAL:  terminating connection due to idle-session timeout
server closed the connection unexpectedly
	This probably means the server terminated abnormally
	before or while processing the request.
The connection to the server was lost. Attempting reset: Succeeded.

and following is recorded on the PostgreSQL log:

746009 2022-05-10 10:01:11.084 JST FATAL:  terminating connection due to idle-session timeout

If we want to be consistent with PostgreSQL, maybe we'd better to keep
the current behavior of client_idle_limit.

Best reagards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp