<div dir="ltr">Hi Gerhard<div><br><div>Many thanks for testing and pointing this out. It&#39;s unfortunate that you are still getting the stuck connection issue. If it is possible can you please share the pgpool-II log for the time when this stuck connection issue happens. I am more interested in seeing which exact error message that caused the child process to jump to error handler from where the child process proceeded to send the DISCARD ALL to backend and eventually got stuck. Since after many tries we are not able to reproduce this issue, so log would be really helpful in understanding and fixing the problem.</div><div><br></div><div>Best regards</div><div>Muhammad Usama</div><div><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jan 31, 2016 at 9:33 PM, Gerhard Wiesinger <span dir="ltr">&lt;<a href="mailto:lists@wiesinger.com" target="_blank">lists@wiesinger.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">On 28.01.2016 01:10, Tatsuo Ishii wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
On 21.01.2016 20:52, Muhammad Usama wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Hi<br>
<br>
I am looking into this issue. and unfortunately like Ishii-San I am<br>
also not able to reproduce it. But I found one issue in 3.4 that might<br>
cause the problem. Can you please try the attached patch if it solves<br>
the problem. Also, if the problem still persists, it would be really<br>
helpful if you could share the pgpool-II log.<br>
<br>
</blockquote>
I looked at the patch but it includes only logging changes and no<br>
functional changes. Therefore I didn&#39;t test it. Do you expect and<br>
behavioral changes to fix it, and why?<br>
</blockquote>
elog() is not only a logging function, but also it plays very<br>
important role including exception handling and error treatments in<br>
pgpool-II. If you are familiar with PostgreSQL internals, you may<br>
notice it (elog() was imported from PostgreSQL source tree).<br>
</blockquote>
<br></span>
Tried version 3.5.0 where the patch is included. Still not working. See backtrace below.<br>
<br>
Reverting to 3.3.7 which works perfectly.<br>
<br>
Ciao,<br>
Gerhard<br>
<br>
(gdb) back<br>
#0  0x00007fd87fdb6d43 in __select_nocancel () from /lib64/libc.so.6<br>
#1  0x0000564471af16a1 in pool_check_fd (cp=cp@entry=0x564473dfa610) at protocol/pool_process_query.c:635<br>
#2  0x0000564471af1976 in pool_check_fd (cp=cp@entry=0x564473dfa610) at protocol/pool_process_query.c:657<br>
#3  0x0000564471b1f67b in pool_read (cp=0x564473dfa610, buf=buf@entry=0x7ffc1d71bf97, len=len@entry=1) at utils/pool_stream.c:162<br>
#4  0x0000564471af8e6e in read_kind_from_backend (frontend=frontend@entry=0x564473df3e60, backend=backend@entry=0x564473df2e00,<br>
    decided_kind=decided_kind@entry=0x7ffc1d71c397 &quot;E&quot;) at protocol/pool_process_query.c:3234<br>
#5  0x0000564471affdc9 in ProcessBackendResponse (frontend=frontend@entry=0x564473df3e60, backend=backend@entry=0x564473df2e00, state=state@entry=0x7ffc1d71c41c,<br>
    num_fields=num_fields@entry=0x7ffc1d71c41a) at protocol/pool_proto_modules.c:2356<br>
#6  0x0000564471af5b15 in pool_process_query (frontend=0x564473df3e60, backend=0x564473df2e00, reset_request=reset_request@entry=1) at protocol/pool_process_query.c:302<br>
#7  0x0000564471aed98c in backend_cleanup (backend=&lt;optimized out&gt;, frontend_invalid=frontend_invalid@entry=0 &#39;\000&#39;, frontend=0x564471e09e40 &lt;child_frontend&gt;)<br>
    at protocol/child.c:437<br>
#8  0x0000564471af0637 in do_child (fds=fds@entry=0x564473dee030) at protocol/child.c:234<br>
#9  0x0000564471ace107 in fork_a_child (fds=0x564473dee030, id=8) at main/pgpool_main.c:678<br>
#10 0x0000564471aceb6d in reaper () at main/pgpool_main.c:2254<br>
#11 0x0000564471ad322b in PgpoolMain (discard_status=&lt;optimized out&gt;, clear_memcache_oidmaps=&lt;optimized out&gt;) at main/pgpool_main.c:429<br>
#12 0x0000564471acc7b1 in main (argc=&lt;optimized out&gt;, argv=0x7ffc1d7219e8) at main/main.c:310<br>
<br>
#1  0x0000564471af16a1 in pool_check_fd (cp=cp@entry=0x564473dfa610) at protocol/pool_process_query.c:635<br>
635                     fds = select(fd+1, &amp;readmask, NULL, &amp;exceptmask, timeoutp);<br>
<br>
(gdb) print fd<br>
$1 = 8<br>
(gdb) print readmask<br>
$2 = {fds_bits = {256, 0 &lt;repeats 15 times&gt;}}<br>
(gdb) print exceptmask<br>
$3 = {fds_bits = {256, 0 &lt;repeats 15 times&gt;}}<br>
(gdb) print timeoutp<br>
$4 = (struct timeval *) 0x0<br>
<br>
<br>
</blockquote></div><br></div></div></div></div>