n
etstat show nothing about the socket of the process,so I think the TCP timeout took effect.so it is really wired.
Jov
blog: http:amutu.com/blog
2013/7/8 Tom Lane <tgl@xxxxxxxxxxxxx>
The backend will keep trying to send data until the kernel informs itMerlin Moncure <mmoncure@xxxxxxxxx> writes:
> On Mon, Jul 8, 2013 at 4:56 AM, Jov <amutu@xxxxxxxxx> 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 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
