<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Hi,<br>
    <br>
        It looks like it hangs in this places (see attachment). Problem
    is, that developer responsible for app has changed something in
    code, so connections now closes properly from client side (before I
    got a lot of these errors:<br>
    <br>
    <span style="color: rgb(44, 45, 48); font-family: Slack-Lato,
      appleLogo, sans-serif; font-size: 15px; font-style: normal;
      font-variant: normal; font-weight: normal; letter-spacing: normal;
      line-height: 22px; orphans: auto; text-align: start; text-indent:
      0px; text-transform: none; white-space: normal; widows: 1;
      word-spacing: 0px; -webkit-text-stroke-width: 0px; display: inline
      !important; float: none; background-color: rgb(255, 255, 255);">2016-02-08
      09:33:39: pid 8472: ERROR:  unable to read data from frontend</span><br
      style="box-sizing: border-box; color: rgb(44, 45, 48);
      font-family: Slack-Lato, appleLogo, sans-serif; font-size: 15px;
      font-style: normal; font-variant: normal; font-weight: normal;
      letter-spacing: normal; line-height: 22px; orphans: auto;
      text-align: start; text-indent: 0px; text-transform: none;
      white-space: normal; widows: 1; word-spacing: 0px;
      -webkit-text-stroke-width: 0px; background-color: rgb(255, 255,
      255);">
    <span style="color: rgb(44, 45, 48); font-family: Slack-Lato,
      appleLogo, sans-serif; font-size: 15px; font-style: normal;
      font-variant: normal; font-weight: normal; letter-spacing: normal;
      line-height: 22px; orphans: auto; text-align: start; text-indent:
      0px; text-transform: none; white-space: normal; widows: 1;
      word-spacing: 0px; -webkit-text-stroke-width: 0px; display: inline
      !important; float: none; background-color: rgb(255, 255, 255);">2016-02-08
      09:33:39: pid 8472: DETAIL:  EOF encountered with frontend)<br>
    </span>. <br>
    <br>
    <pre class="moz-signature" cols="72">Best regards,
Paweł Ufnalewski
Infrastructure Architect at Foap.com</pre>
    <div class="moz-cite-prefix">W dniu 2016-02-08 o 09:00, Muhammad
      Usama pisze:<br>
    </div>
    <blockquote
cite="mid:CAEJvTzU97EAL+sdXwW2LrCPhmot-eiHh93C1S1C0uwRt+0MuKg@mail.gmail.com"
      type="cite">
      <pre wrap="">Hi

Thanks in advance for the help. If you could share the pgpool-II log
when the stuck connection happens that would help us in identifiny and
rectifing the problem.

Thanks
Best regards
Muhammad Usama


On Mon, Feb 8, 2016 at 11:36 AM, Paweł Ufnalewski <a class="moz-txt-link-rfc2396E" href="mailto:archon@foap.com">&lt;archon@foap.com&gt;</a> wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="">
Hi,

    just to let you know - I'm having the same problem with 3.4.4 version (DISCARD ALL appears slower than in 3.4.3 I think, but it still does). How can I help to fix this problem?

Best regards,
Paweł Ufnalewski
Infrastructure Architect at Foap.com

W dniu 2016-02-01 o 08:44, Muhammad Usama pisze:

Hi Gerhard

Many thanks for testing and pointing this out. It'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.

Best regards
Muhammad Usama


On Sun, Jan 31, 2016 at 9:33 PM, Gerhard Wiesinger <a class="moz-txt-link-rfc2396E" href="mailto:lists@wiesinger.com">&lt;lists@wiesinger.com&gt;</a> wrote:
</pre>
        <blockquote type="cite">
          <pre wrap="">
On 28.01.2016 01:10, Tatsuo Ishii wrote:
</pre>
          <blockquote type="cite">
            <blockquote type="cite">
              <pre wrap="">
On 21.01.2016 20:52, Muhammad Usama wrote:
</pre>
              <blockquote type="cite">
                <pre wrap="">
Hi

I am looking into this issue. and unfortunately like Ishii-San I am
also not able to reproduce it. But I found one issue in 3.4 that might
cause the problem. Can you please try the attached patch if it solves
the problem. Also, if the problem still persists, it would be really
helpful if you could share the pgpool-II log.

</pre>
              </blockquote>
              <pre wrap="">I looked at the patch but it includes only logging changes and no
functional changes. Therefore I didn't test it. Do you expect and
behavioral changes to fix it, and why?
</pre>
            </blockquote>
            <pre wrap="">
elog() is not only a logging function, but also it plays very
important role including exception handling and error treatments in
pgpool-II. If you are familiar with PostgreSQL internals, you may
notice it (elog() was imported from PostgreSQL source tree).
</pre>
          </blockquote>
          <pre wrap="">

Tried version 3.5.0 where the patch is included. Still not working. See backtrace below.

Reverting to 3.3.7 which works perfectly.

Ciao,
Gerhard

(gdb) back
#0  0x00007fd87fdb6d43 in __select_nocancel () from /lib64/libc.so.6
#1  0x0000564471af16a1 in pool_check_fd (cp=cp@entry=0x564473dfa610) at protocol/pool_process_query.c:635
#2  0x0000564471af1976 in pool_check_fd (cp=cp@entry=0x564473dfa610) at protocol/pool_process_query.c:657
#3  0x0000564471b1f67b in pool_read (cp=0x564473dfa610, buf=buf@entry=0x7ffc1d71bf97, len=len@entry=1) at utils/pool_stream.c:162
#4  0x0000564471af8e6e in read_kind_from_backend (frontend=frontend@entry=0x564473df3e60, backend=backend@entry=0x564473df2e00,
    decided_kind=decided_kind@entry=0x7ffc1d71c397 "E") at protocol/pool_process_query.c:3234
#5  0x0000564471affdc9 in ProcessBackendResponse (frontend=frontend@entry=0x564473df3e60, backend=backend@entry=0x564473df2e00, state=state@entry=0x7ffc1d71c41c,
    num_fields=num_fields@entry=0x7ffc1d71c41a) at protocol/pool_proto_modules.c:2356
#6  0x0000564471af5b15 in pool_process_query (frontend=0x564473df3e60, backend=0x564473df2e00, reset_request=reset_request@entry=1) at protocol/pool_process_query.c:302
#7  0x0000564471aed98c in backend_cleanup (backend=&lt;optimized out&gt;, frontend_invalid=frontend_invalid@entry=0 '\000', frontend=0x564471e09e40 &lt;child_frontend&gt;)
    at protocol/child.c:437
#8  0x0000564471af0637 in do_child (fds=fds@entry=0x564473dee030) at protocol/child.c:234
#9  0x0000564471ace107 in fork_a_child (fds=0x564473dee030, id=8) at main/pgpool_main.c:678
#10 0x0000564471aceb6d in reaper () at main/pgpool_main.c:2254
#11 0x0000564471ad322b in PgpoolMain (discard_status=&lt;optimized out&gt;, clear_memcache_oidmaps=&lt;optimized out&gt;) at main/pgpool_main.c:429
#12 0x0000564471acc7b1 in main (argc=&lt;optimized out&gt;, argv=0x7ffc1d7219e8) at main/main.c:310

#1  0x0000564471af16a1 in pool_check_fd (cp=cp@entry=0x564473dfa610) at protocol/pool_process_query.c:635
635                     fds = select(fd+1, &amp;readmask, NULL, &amp;exceptmask, timeoutp);

(gdb) print fd
$1 = 8
(gdb) print readmask
$2 = {fds_bits = {256, 0 &lt;repeats 15 times&gt;}}
(gdb) print exceptmask
$3 = {fds_bits = {256, 0 &lt;repeats 15 times&gt;}}
(gdb) print timeoutp
$4 = (struct timeval *) 0x0


</pre>
        </blockquote>
        <pre wrap="">


_______________________________________________
pgpool-general mailing list
<a class="moz-txt-link-abbreviated" href="mailto:pgpool-general@pgpool.net">pgpool-general@pgpool.net</a>
<a class="moz-txt-link-freetext" href="http://www.pgpool.net/mailman/listinfo/pgpool-general">http://www.pgpool.net/mailman/listinfo/pgpool-general</a>


</pre>
      </blockquote>
    </blockquote>
    <br>
  </body>
</html>