[Pgpool-general] how to force pgpool to release client connections?

[Tatsuo Ishii]

> ;) that is my same problem and the only way I have now is by  
> restarting apache ( in your case mongrel I guess)  which then closes  
> the connections which sucks cause it kicks out all clients even the  
> ones not doing anything with pgpool. Apache reload won't work.
> 
> I have also tried setting client_idle_limit but the problem with that  
> is that will kill not only just idle but also idle in transaction at  
> any time.

Changing the behaviro of client_idle_limit in that it will not kill
clients in the idle_in_transaction_state is not too hard. Is this what
you want? Or should we have new switch to keep the current behavior
(kill idle clients in whatever state?

> it would be nice if there was a variable like that is just picked up  
> during online recovery, so that if online recovery is occurring and  
> there are idle connections or idle in transactions get ready of them.

Ok, what about having new switch:

client_idle_limit_in_recovery

BTW, do we have to kill clients immediately even if they are *not*
idle in online recovery as Tiago said?

> I tried the patch below on the CVS head but that will take care of  
> other connection issues I guess.

Right.
--
Tatsuo Ishii
SRA OSS, Inc. Japan

> Marcelo
> 
> On Oct 29, 2008, at 11:37 AM, Tiago Macedo wrote:
> 
> > Hi,
> >
> > I'm having a similar issue in the beginning of the 2nd recovery  
> > stage. If I have open connections (in this case ActiveRecord  
> > connections) that never disconnect by themselves, the recovery will  
> > timeout. Is there anyway to force pgpool-II to close those  
> > connections?
> >
> > At the moment my client_idle_limit is 0 in order for pgpool and  
> > rails to get along well but I don't think tweaking that value would  
> > actually help if the connection isn't idle.
> >
> > I'm not familiar with the pgpool source so I'm not sure what this  
> > patch achieves, does it do what I need and kill the client connection?
> >
> > Thanks,
> > Tiago Macedo
> >
> > On Thu, Oct 23, 2008 at 2:53 PM, Tatsuo Ishii <ishii at sraoss.co.jp>  
> > wrote:
> > > Hello,
> > >
> > > I have faced with the problem of "zombie" connections that  
> > prevents starting
> > > the second stage of on-line recovery process.
> > > The zombie connections are between clients behind the firewall  
> > that are
> > > unexpectedly disapeared.
> > > The pgpool sends RESEST after client_idle_limit seconds, but if no  
> > client
> > > exists on the remote site this connection is waiting in CLOSE-WAIT  
> > state
> > > till ...
> >
> > pgpool does not send RESET request to the client, but to the
> > backend. So your problem seems to be caused by pgpool calling close(2)
> > the connection to client.
> >
> > Can you try included patches which try to avoid the problem by using
> > shutdown(2)?
> > --
> > Tatsuo Ishii
> > SRA OSS, Inc. Japan
> >
> > Index: pool_stream.c
> > ===================================================================
> > RCS file: /cvsroot/pgpool/pgpool-II/pool_stream.c,v
> > retrieving revision 1.12
> > diff -c -r1.12 pool_stream.c
> > *** pool_stream.c       4 Jul 2008 05:27:30 -0000       1.12
> > --- pool_stream.c       23 Oct 2008 13:51:26 -0000
> > ***************
> > *** 95,101 ****
> > --- 95,107 ----
> >  */
> >  void pool_close(POOL_CONNECTION *cp)
> >  {
> > +       /*
> > +        * shutdown connection to the client so that pgpool is not  
> > blocked
> > +        */
> > +       if (!cp->isbackend)
> > +               shutdown(cp->fd, 1);
> >        close(cp->fd);
> > +
> >        free(cp->wbuf);
> >        free(cp->hp);
> >        if (cp->sbuf)
> >
> > _______________________________________________
> > Pgpool-general mailing list
> > Pgpool-general at pgfoundry.org
> > http://pgfoundry.org/mailman/listinfo/pgpool-general
> >
> >
> > _______________________________________________
> > Pgpool-general mailing list
> > Pgpool-general at pgfoundry.org
> > http://pgfoundry.org/mailman/listinfo/pgpool-general
>