Re: BUG #5465: dblink TCP connection hangs blocking translation from being terminated

From: valgog <valgog(at)gmail(dot)com>
To: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #5465: dblink TCP connection hangs blocking translation from being terminated
Date: 2010-05-21 07:45:37
Message-ID: 96a41caa-20c3-455d-a557-680fb9e3cdc5@v37g2000vbv.googlegroups.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On May 19, 8:41 pm, m(dot)(dot)(dot)(at)joeconway(dot)com (Joseph Conway) wrote:
> Magnus Hagander wrote:
> > On Wed, May 19, 2010 at 5:10 AM, Valentine Gogichashvili
> > <val(dot)(dot)(dot)(at)gmail(dot)com> wrote:
> >> The following bug has been logged online:
>
> >> Bug reference:      5465
> >> Logged by:          Valentine Gogichashvili
> >> Email address:      val(dot)(dot)(dot)(at)gmail(dot)com
> >> PostgreSQL version: 8.2.1
> >> Operating system:   Red Hat 3.4.6-3 (kernel 2.6.9-42.0.3.ELsmp)
> >> Description:        dblink TCP connection hangs blocking translation from
> >> being terminated
> >> Details:
>
> >> Hi all,
>
> >> we have an issue on our productive server. A stored procedure, that uses
> >> dblink to get some data from the remote database hangs not responding to
> >> kill signal and holds several locks on some tables as well as an advisory
> >> lock. So I have this transaction to be completed in order to have a
> >> possibility to operate the database normally.
>
> > I believe this is a known issue in dblink, where it's not possible to
> > cancel it when it's waiting in the TCP layer in the kernel.
> > Unfortunately, there is no fix ATM - there was some work towards it
> > for 9.0 at one point, but I think this is actually the first real
> > bug-report on the issue...
>
> I thought the known issue was only on Windows though...
> Note that this is not dblink specific but rather libpq.
>
> >> How would it be possible to shutdown the DB in case this session process is
> >> not responding to normal kill signals? Will it hinder the database from
> >> shutting down normally? My previous experience with issuing immediate stops
> >> or killing with -9 had been quite catastrophic and I could not start the DB
> >> afterwards. What would you suggest in this case?
>
> > kill -9 on a client will make the postmaster restart the whole
> > process, so yes, it's a very heavy operation.
>
> Can you grab the process with gdb and call elog() manually?
>
> Joe
>
> --
> Sent via pgsql-bugs mailing list (pgsql-b(dot)(dot)(dot)(at)postgresql(dot)org)
> To make changes to your subscription:http://www.postgresql.org/mailpref/pgsql-bugs

Unfortunately I could not install gdb on that machine :-( some
dependencies are not installable and I cannot upgrade that production
machine...

-- Valentine

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message valgog 2010-05-21 07:48:36 Re: BUG #5465: dblink TCP connection hangs blocking transaction from being terminated
Previous Message Michael Meskes 2010-05-20 22:11:40 Re: BUG #5464: ecpg on 64bit system converts "long long" to "long"