From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
Cc: | Jov <amutu(at)amutu(dot)com>, Bill Mitchell <bill(at)publicrelay(dot)com>, pgsql-general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: backend hangs at sendto() and can't be terminated |
Date: | 2013-07-08 13:15:33 |
Message-ID: | 27580.1373289333@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Merlin Moncure <mmoncure(at)gmail(dot)com> writes:
> On Mon, Jul 8, 2013 at 4:56 AM, Jov <amutu(at)amutu(dot)com> wrote:
>> my first post already try the pg_terminate_backend but failed:
>> pg_terminate_backend return t but the backend still there.
> possibly a kernel problem?
The backend will keep trying to send data until the kernel informs it
the connection is lost. (Anything else would be a bad idea.) So the
real question here is why it's taking so long for the TCP stack to
decide that the client is gone. I'm wondering what exactly you did
to kill the psql session. Most ordinary ways of killing a process
should result in closure of whatever connections it had open.
If you'd lost network connectivity to the client, a TCP timeout on the
order of an hour wouldn't be surprising. (If you feel this is too long,
you can fool with the TCP keepalive parameters.) But it seems unlikely
that that's what's happening here.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Jov | 2013-07-08 13:48:53 | Re: backend hangs at sendto() and can't be terminated |
Previous Message | Atri Sharma | 2013-07-08 13:14:38 | Re: Longest Common Subsequence in Postgres - Algorithm Challenge |