[pgpool-general: 2930] Re: Connections stuck in CLOSE_WAIT, again
melguy at gmail.com
Thu Jun 19 17:48:20 JST 2014
I have the same problem with PuppetDB fortend.
When I stop the service of PuppetDB, all connections from pgpool is
CLOSE_WAIT and in DISCARD state, even with connection timeout set to 1
here is the summery from gdb:
the hanged function is:
__select_no_cancel() from /lib64/libc.so.6.
0 __select_no_cancel() from /lib64/libc.so.6.
On Thu, Jun 19, 2014 at 2:29 AM, Tatsuo Ishii <ishii at postgresql.org> wrote:
> You said your developer found pgpool child process in DISCARD state.
> Please attach gdb to the process in DISCARD state and take
> backtrace. Also I need actual netsta -anp outputs.
> Best regards,
> Tatsuo Ishii
> SRA OSS, Inc. Japan
> English: http://www.sraoss.co.jp/index_en.php
> > Hi Tatsuo,
> > We are facing this same problem, and as I see it remains unsolved (or
> > perhaps they didn't report the solution).
> > We are using pgpool 3.3.3, with two postgres 9.1 in streaming
> > replication. The OS is Debian 3.2.54-2 (64bits).
> > The log shows messages like this:
> > ProcessFrontendResponse: failed to read kind from frontend.
> > abnormally exited
> > I'm not sure but it looks like one for each connection left unclosed.
> > Also, a ps -ef returns a lot of pgpool children in DISCARD state. And
> > the netstat -anp, gives the correspondent TCP connection in
> > state.
> > The developer has checked the client process is closing the
> > connections and we try connecting directly to the postgres and it
> > worked fine.
> > When you say "to attach debugger", do you mean change log_statment =
> > true or debug_level to a value other than 0 or any other procedure?
> > Many thanks,
> > --
> > Juanjo Pérez
> > www.oteara.com
> > El 02/04/14 01:05, Tatsuo Ishii escribió:
> >>> We have a client on 3.3 experiencing the the problem noted here:
> >>> strace is showing the child processes at:
> >>> clone(child_stack=0,
> >>> flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
> >>> child_tidptr=0x7fcf659f3a10) = 6258
> >>> I didn't see any resolution of that issue; is there data we can gather
> >>> to assist?
> >> I followed the old 2012 posting with:
> >>> That means pgpool does not close the socket connected to by your
> >>> applications. Is it possible to attach debugger to such that pgpool
> >>> process to see what pgpool is doing?
> >> But I got no response until now. Can you please do this?
> >> Best regards,
> >> --
> >> Tatsuo Ishii
> >> SRA OSS, Inc. Japan
> >> English: http://www.sraoss.co.jp/index_en.php
> >> Japanese: http://www.sraoss.co.jp
> >> _______________________________________________
> >> pgpool-general mailing list
> >> pgpool-general at pgpool.net
> >> http://www.pgpool.net/mailman/listinfo/pgpool-general
> > _______________________________________________
> > pgpool-general mailing list
> > pgpool-general at pgpool.net
> > http://www.pgpool.net/mailman/listinfo/pgpool-general
> pgpool-general mailing list
> pgpool-general at pgpool.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the pgpool-general