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 <http://amutu.com/blog> 2013/7/8 Tom Lane <t...@sss.pgh.pa.us> > Merlin Moncure <mmonc...@gmail.com> writes: > > On Mon, Jul 8, 2013 at 4:56 AM, Jov <am...@amutu.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 > >
