<div dir="ltr">Hi Ishii San<div><br></div><div>I think this difference of behavior between 3.3. And 3.4 is caused by the commit &quot;cb735f22441001b6afdbb5bac72808db66094ca9&quot; that was not ported to the 3.4 branch.</div><div><br></div><div><a href="http://git.postgresql.org/gitweb/?p=pgpool2.git;a=commit;h=cb735f22441001b6afdbb5bac72808db66094ca9">http://git.postgresql.org/gitweb/?p=pgpool2.git;a=commit;h=cb735f22441001b6afdbb5bac72808db66094ca9</a><br></div><div><br></div><div>Thanks</div><div>Best regards</div><div>Muhammad Usama</div><div><br></div><div><br></div>







</div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 13, 2015 at 2:45 PM, Tatsuo Ishii <span dir="ltr">&lt;<a href="mailto:ishii@postgresql.org" target="_blank">ishii@postgresql.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">&gt; Usama,<br>
&gt;<br>
&gt; While I have been working on:<br>
&gt; <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>
</span>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>
<div class="HOEnZb"><div class="h5"><br>
&gt; I found there was an interesting behavior change between pgpool-II 3.3<br>
&gt; and 3.4.<br>
&gt;<br>
&gt; It turns out that the bug was related to the action when<br>
&gt; client_idle_limit is reached. In 3.3, when client_idle_limit is<br>
&gt; reached, following statement is executed (pool_process_query.c):<br>
&gt;<br>
&gt; if (idle_count &gt; pool_config-&gt;client_idle_limit)<br>
&gt; {<br>
&gt;       pool_log(&quot;pool_process_query: child connection forced to terminate due to client_idle_limit (%d) reached,<br>
&gt;                pool_config-&gt;client_idle_limit);<br>
&gt;               pool_send_error_message(frontend, MAJOR(backend),<br>
&gt;               &quot;57000&quot;, &quot;connection terminated due to client idle limit reached&quot;,<br>
&gt;                                       &quot;&quot;,&quot;&quot;,  __FILE__, __LINE__);<br>
&gt;       return POOL_END_WITH_FRONTEND_ERROR;<br>
&gt; }<br>
&gt;<br>
&gt; then goes to this (child.c)<br>
&gt;<br>
&gt; if (status == POOL_END_WITH_FRONTEND_ERROR ||<br>
&gt;    pool_config-&gt;connection_cache == 0 ||<br>
&gt;    !strcmp(sp-&gt;database, &quot;template0&quot;) ||<br>
&gt;    !strcmp(sp-&gt;database, &quot;template1&quot;) ||<br>
&gt;    !strcmp(sp-&gt;database, &quot;postgres&quot;) ||<br>
&gt;    !strcmp(sp-&gt;database, &quot;regression&quot;))<br>
&gt; {<br>
&gt;       reset_connection();<br>
&gt;       pool_close(frontend);<br>
&gt;       pool_send_frontend_exits(backend);<br>
&gt;       pool_discard_cp(sp-&gt;user, sp-&gt;database, sp-&gt;major);<br>
&gt; }<br>
&gt;<br>
&gt; This results in closing connection to backend.<br>
&gt;<br>
&gt; In 3.4,<br>
&gt;<br>
&gt; if (idle_count &gt; pool_config-&gt;client_idle_limit)<br>
&gt; {<br>
&gt;       ereport(ERROR,<br>
&gt;            (pool_error_code(&quot;57000&quot;),<br>
&gt;                errmsg(&quot;unable to read data&quot;),<br>
&gt;                  errdetail(&quot;child connection forced to terminate due to client_idle_limit:%d is reached&quot;,<br>
&gt;                   pool_config-&gt;client_idle_limit)));<br>
&gt; }<br>
&gt;<br>
&gt; Then jump to backend_cleanup() and call pool_process_query() to<br>
&gt; execute queries defined in reset_query_list. This results in sending<br>
&gt; typically &quot;DISCARD ALL&quot; to backend. The problem reported in the bug id<br>
&gt; 147 happens in this route (actually the reporter claims that pgpool-II<br>
&gt; hangs in sending &quot;DISCARD&quot;).<br>
&gt;<br>
&gt; In summary, when client idle limit reaches, pgpool-II 3.3 disconnects<br>
&gt; connections to backend, while 3.4 does not close the connections to<br>
&gt; backend and sends DISCARD to backend.<br>
&gt;<br>
&gt; We have a few reports that pgpool-II 3.4 hangs while sending DISCARD<br>
&gt; and I wonder those problems somewhat related to the behavior change<br>
&gt; described above because the code path in 3.4 is executed even if<br>
&gt; client_idle_limit is not reached (elog(ERROR...)).<br>
&gt;<br>
&gt; Usama,<br>
&gt;<br>
&gt; Was this behavior change intentional?<br>
&gt;<br>
&gt; Best regards,<br>
&gt; --<br>
&gt; Tatsuo Ishii<br>
&gt; SRA OSS, Inc. Japan<br>
&gt; 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>
&gt; Japanese:<a href="http://www.sraoss.co.jp" rel="noreferrer" target="_blank">http://www.sraoss.co.jp</a><br>
&gt; _______________________________________________<br>
&gt; pgpool-hackers mailing list<br>
&gt; <a href="mailto:pgpool-hackers@pgpool.net">pgpool-hackers@pgpool.net</a><br>
&gt; <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>
</div></div></blockquote></div><br></div>