[pgpool-general: 4312] Re: Pgpool - connection hangs in DISCARD ALL
mkeir at redhat.com
Fri Jan 8 16:20:08 JST 2016
There is a reproduction script and scenario in http://www.pgpool.net/mantisbt/view.php?id=147
----- Original Message -----
> From: "Gerhard Wiesinger" <lists at wiesinger.com>
> To: "Tatsuo Ishii" <ishii at postgresql.org>
> Cc: pgpool-general at pgpool.net
> Sent: Friday, January 8, 2016 5:00:05 PM
> Subject: [pgpool-general: 4311] Re: Pgpool - connection hangs in DISCARD ALL
> On 08.01.2016 07:32, Tatsuo Ishii wrote:
> >> On 07.01.2016 22:32, Tatsuo Ishii wrote:
> >>> I heard similar reports but problem for developers is, nobody knows
> >>> how to reproduce the hang (a stack trace after the hang is not very
> >>> helpful).
> >> Yes, there were already 2? on the list.
> >> I can reproduce it randomly in about one day. I think stack traces
> >> should be sufficient when e.g. debug code has been added.
> > No. That's just a consequence of many problems including this one.
> >> How to track the bug down?
> >> Debug code?
> >> Enhanced logging?
> > A debug logging would be helpful (start pgpool with -d option) but it
> > will consume huge disk space if you want to save all off them. Is it
> > possible to keep only last 30 minues debug logs before the problem
> > occurs? I guess even 10 minutes is enough to know the cause of the
> > problem.
> Can you try to reproduce it, too?
> My use case is very simple:
> 1.) One persistent connection with username1/database1 doing an insert
> every minute
> 2.) Nagios bombs out about 10 simple SELECT queries every minute with
> username2/database1 nearly at the same time (so it looks like sometimes
> same backend connection can be used)
> So should be easy to test. I close the unused backend connections after
> 2s, so if you bomb e.g. every 10s should be fast to reproduce.
> Happens in my case in 0.5-24h.
> pgpool-general mailing list
> pgpool-general at pgpool.net
More information about the pgpool-general