Magnus Hagander wrote:
> On Wed, May 19, 2010 at 5:10 AM, Valentine Gogichashvili
> <valgog@gmail.com> wrote:
>> The following bug has been logged online:
>>
>> Bug reference: 5465
>> Logged by: Valentine Gogichashvili
>> Email address: valgog@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
