[pgpool-hackers: 1098] Re: pgpool-II 3.4 problems

Tatsuo Ishii ishii at postgresql.org
Tue Oct 13 18:45:35 JST 2015


> Usama,
> 
> While I have been working on:
> http://www.pgpool.net/mantisbt/view.php?id=147

Oops. This is wrong. Here is the correct one.

http://www.pgpool.net/mantisbt/view.php?id=145

> I found there was an interesting behavior change between pgpool-II 3.3
> and 3.4.
> 
> It turns out that the bug was related to the action when
> client_idle_limit is reached. In 3.3, when client_idle_limit is
> reached, following statement is executed (pool_process_query.c):
> 
> if (idle_count > pool_config->client_idle_limit)
> {
> 	pool_log("pool_process_query: child connection forced to terminate due to client_idle_limit (%d) reached,
> 		 pool_config->client_idle_limit);
> 		pool_send_error_message(frontend, MAJOR(backend),
> 		"57000", "connection terminated due to client idle limit reached",
> 					"","",  __FILE__, __LINE__);
> 	return POOL_END_WITH_FRONTEND_ERROR;
> }
> 
> then goes to this (child.c)
> 
> if (status == POOL_END_WITH_FRONTEND_ERROR ||
>    pool_config->connection_cache == 0 ||
>    !strcmp(sp->database, "template0") ||
>    !strcmp(sp->database, "template1") ||
>    !strcmp(sp->database, "postgres") ||
>    !strcmp(sp->database, "regression"))
> {
> 	reset_connection();
> 	pool_close(frontend);
> 	pool_send_frontend_exits(backend);
> 	pool_discard_cp(sp->user, sp->database, sp->major);
> }
> 
> This results in closing connection to backend.
> 
> In 3.4, 
> 
> if (idle_count > pool_config->client_idle_limit)
> {
> 	ereport(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)));
> }
> 
> Then jump to backend_cleanup() and call pool_process_query() to
> execute queries defined in reset_query_list. This results in sending
> typically "DISCARD ALL" to backend. The problem reported in the bug id
> 147 happens in this route (actually the reporter claims that pgpool-II
> hangs in sending "DISCARD").
> 
> In summary, when client idle limit reaches, pgpool-II 3.3 disconnects
> connections to backend, while 3.4 does not close the connections to
> backend and sends DISCARD to backend.
> 
> We have a few reports that pgpool-II 3.4 hangs while sending DISCARD
> and I wonder those problems somewhat related to the behavior change
> described above because the code path in 3.4 is executed even if
> client_idle_limit is not reached (elog(ERROR...)).
> 
> Usama,
> 
> Was this behavior change intentional?
> 
> Best regards,
> --
> Tatsuo Ishii
> SRA OSS, Inc. Japan
> English: http://www.sraoss.co.jp/index_en.php
> Japanese:http://www.sraoss.co.jp
> _______________________________________________
> pgpool-hackers mailing list
> pgpool-hackers at pgpool.net
> http://www.pgpool.net/mailman/listinfo/pgpool-hackers


More information about the pgpool-hackers mailing list