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

[Tiago Macedo]

Hi,

I would love that client_idle_time_in_recovery as it would be an easy way to
disconnect clients "gently" when the 2nd stage of recovery starts and still
allow permanent idle connections during normal operations. Either that or
immediately kill all connections when the 2nd stage starts would work for my
needs.

Other than that minor issue the whole pgpool online-recovery works *really*
well.

Thanks,
Tiago Macedo

On Thu, Oct 30, 2008 at 6:02 AM, Tatsuo Ishii <ishii at sraoss.co.jp> wrote:

> > ;) 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
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://pgfoundry.org/pipermail/pgpool-general/attachments/20081030/eb903a1b/attachment.html