Re: BUG #5465: dblink TCP connection hangs blocking translation from being terminated
От | valgog |
---|---|
Тема | Re: BUG #5465: dblink TCP connection hangs blocking translation from being terminated |
Дата | |
Msg-id | 96a41caa-20c3-455d-a557-680fb9e3cdc5@v37g2000vbv.googlegroups.com обсуждение исходный текст |
Ответ на | BUG #5465: dblink TCP connection hangs blocking translation from being terminated ("Valentine Gogichashvili" <valgog@gmail.com>) |
Список | pgsql-bugs |
On May 19, 8:41=A0pm, m...@joeconway.com (Joseph Conway) wrote: > Magnus Hagander wrote: > > On Wed, May 19, 2010 at 5:10 AM, Valentine Gogichashvili > > <val...@gmail.com> wrote: > >> The following bug has been logged online: > > >> Bug reference: =A0 =A0 =A05465 > >> Logged by: =A0 =A0 =A0 =A0 =A0Valentine Gogichashvili > >> Email address: =A0 =A0 =A0val...@gmail.com > >> PostgreSQL version: 8.2.1 > >> Operating system: =A0 Red Hat 3.4.6-3 (kernel 2.6.9-42.0.3.ELsmp) > >> Description: =A0 =A0 =A0 =A0dblink TCP connection hangs blocking trans= lation from > >> being terminated > >> Details: > > >> Hi all, > > >> we have an issue on our productive server. A stored procedure, that us= es > >> 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 advis= ory > >> 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 proce= ss 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 t= he 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...@postgresql.org) > To make changes to your subscription:http://www.postgresql.org/mailpref/p= gsql-bugs Unfortunately I could not install gdb on that machine :-( some dependencies are not installable and I cannot upgrade that production machine... -- Valentine
В списке pgsql-bugs по дате отправления: