<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 15, 2015 at 2:23 AM, Tatsuo Ishii <span dir="ltr"><<a href="mailto:ishii@postgresql.org" target="_blank">ishii@postgresql.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Usama,<br>
<br>
Can you please propose a patch to implement similar thing with 3.4? I<br>
think it will make 3.4 more robust. I have no idea how to implement<br>
it with 3.4's exception mechanism.<br></blockquote><div><br></div><div>sure I will work on this</div><div><br></div><div>Thanks</div><div>best regards</div><div>Muhammad Usama </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
Best regards,<br>
--<br>
Tatsuo Ishii<br>
SRA OSS, Inc. Japan<br>
English: <a href="http://www.sraoss.co.jp/index_en.php" rel="noreferrer" target="_blank">http://www.sraoss.co.jp/index_en.php</a><br>
Japanese:<a href="http://www.sraoss.co.jp" rel="noreferrer" target="_blank">http://www.sraoss.co.jp</a><br>
<br>
> Hi Ishii San<br>
><br>
> I think this difference of behavior between 3.3. And 3.4 is caused by the<br>
> commit "cb735f22441001b6afdbb5bac72808db66094ca9" that was not ported to<br>
> the 3.4 branch.<br>
><br>
> <a href="http://git.postgresql.org/gitweb/?p=pgpool2.git;a=commit;h=cb735f22441001b6afdbb5bac72808db66094ca9" rel="noreferrer" target="_blank">http://git.postgresql.org/gitweb/?p=pgpool2.git;a=commit;h=cb735f22441001b6afdbb5bac72808db66094ca9</a><br>
><br>
> Thanks<br>
> Best regards<br>
> Muhammad Usama<br>
><br>
><br>
><br>
> On Tue, Oct 13, 2015 at 2:45 PM, Tatsuo Ishii <<a href="mailto:ishii@postgresql.org">ishii@postgresql.org</a>> wrote:<br>
><br>
>> > Usama,<br>
>> ><br>
>> > While I have been working on:<br>
>> > <a href="http://www.pgpool.net/mantisbt/view.php?id=147" rel="noreferrer" target="_blank">http://www.pgpool.net/mantisbt/view.php?id=147</a><br>
>><br>
>> Oops. This is wrong. Here is the correct one.<br>
>><br>
>> <a href="http://www.pgpool.net/mantisbt/view.php?id=145" rel="noreferrer" target="_blank">http://www.pgpool.net/mantisbt/view.php?id=145</a><br>
>><br>
>> > I found there was an interesting behavior change between pgpool-II 3.3<br>
>> > and 3.4.<br>
>> ><br>
>> > It turns out that the bug was related to the action when<br>
>> > client_idle_limit is reached. In 3.3, when client_idle_limit is<br>
>> > reached, following statement is executed (pool_process_query.c):<br>
>> ><br>
>> > if (idle_count > pool_config->client_idle_limit)<br>
>> > {<br>
>> > pool_log("pool_process_query: child connection forced to terminate<br>
>> due to client_idle_limit (%d) reached,<br>
>> > pool_config->client_idle_limit);<br>
>> > pool_send_error_message(frontend, MAJOR(backend),<br>
>> > "57000", "connection terminated due to client idle limit<br>
>> reached",<br>
>> > "","", __FILE__, __LINE__);<br>
>> > return POOL_END_WITH_FRONTEND_ERROR;<br>
>> > }<br>
>> ><br>
>> > then goes to this (child.c)<br>
>> ><br>
>> > if (status == POOL_END_WITH_FRONTEND_ERROR ||<br>
>> > pool_config->connection_cache == 0 ||<br>
>> > !strcmp(sp->database, "template0") ||<br>
>> > !strcmp(sp->database, "template1") ||<br>
>> > !strcmp(sp->database, "postgres") ||<br>
>> > !strcmp(sp->database, "regression"))<br>
>> > {<br>
>> > reset_connection();<br>
>> > pool_close(frontend);<br>
>> > pool_send_frontend_exits(backend);<br>
>> > pool_discard_cp(sp->user, sp->database, sp->major);<br>
>> > }<br>
>> ><br>
>> > This results in closing connection to backend.<br>
>> ><br>
>> > In 3.4,<br>
>> ><br>
>> > if (idle_count > pool_config->client_idle_limit)<br>
>> > {<br>
>> > ereport(ERROR,<br>
>> > (pool_error_code("57000"),<br>
>> > errmsg("unable to read data"),<br>
>> > errdetail("child connection forced to terminate due to<br>
>> client_idle_limit:%d is reached",<br>
>> > pool_config->client_idle_limit)));<br>
>> > }<br>
>> ><br>
>> > Then jump to backend_cleanup() and call pool_process_query() to<br>
>> > execute queries defined in reset_query_list. This results in sending<br>
>> > typically "DISCARD ALL" to backend. The problem reported in the bug id<br>
>> > 147 happens in this route (actually the reporter claims that pgpool-II<br>
>> > hangs in sending "DISCARD").<br>
>> ><br>
>> > In summary, when client idle limit reaches, pgpool-II 3.3 disconnects<br>
>> > connections to backend, while 3.4 does not close the connections to<br>
>> > backend and sends DISCARD to backend.<br>
>> ><br>
>> > We have a few reports that pgpool-II 3.4 hangs while sending DISCARD<br>
>> > and I wonder those problems somewhat related to the behavior change<br>
>> > described above because the code path in 3.4 is executed even if<br>
>> > client_idle_limit is not reached (elog(ERROR...)).<br>
>> ><br>
>> > Usama,<br>
>> ><br>
>> > Was this behavior change intentional?<br>
>> ><br>
>> > Best regards,<br>
>> > --<br>
>> > Tatsuo Ishii<br>
>> > SRA OSS, Inc. Japan<br>
>> > English: <a href="http://www.sraoss.co.jp/index_en.php" rel="noreferrer" target="_blank">http://www.sraoss.co.jp/index_en.php</a><br>
>> > Japanese:<a href="http://www.sraoss.co.jp" rel="noreferrer" target="_blank">http://www.sraoss.co.jp</a><br>
>> > _______________________________________________<br>
>> > pgpool-hackers mailing list<br>
>> > <a href="mailto:pgpool-hackers@pgpool.net">pgpool-hackers@pgpool.net</a><br>
>> > <a href="http://www.pgpool.net/mailman/listinfo/pgpool-hackers" rel="noreferrer" target="_blank">http://www.pgpool.net/mailman/listinfo/pgpool-hackers</a><br>
>> _______________________________________________<br>
>> pgpool-hackers mailing list<br>
>> <a href="mailto:pgpool-hackers@pgpool.net">pgpool-hackers@pgpool.net</a><br>
>> <a href="http://www.pgpool.net/mailman/listinfo/pgpool-hackers" rel="noreferrer" target="_blank">http://www.pgpool.net/mailman/listinfo/pgpool-hackers</a><br>
>><br>
</div></div></blockquote></div><br></div></div>