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: 5465 >> Logged by: Valentine Gogichashvili >> Email address: val...@gmail.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-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
