[pgpool-hackers: 1097] pgpool-II 3.4 problems
Tatsuo Ishii
ishii at postgresql.org
Tue Oct 13 18:31:23 JST 2015
Usama,
While I have been working on:
http://www.pgpool.net/mantisbt/view.php?id=147
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
More information about the pgpool-hackers
mailing list