From: | Jov <amutu(at)amutu(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Merlin Moncure <mmoncure(at)gmail(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:48:53 |
Message-ID: | CADyrUxO1g7mEGbPrWiEtseJ3UG0US374RehOWkvDUbbp0U4pUw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
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 <tgl(at)sss(dot)pgh(dot)pa(dot)us>
> 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 | pg noob | 2013-07-08 13:54:13 | Re: odd locking behaviour |
Previous Message | Tom Lane | 2013-07-08 13:15:33 | Re: backend hangs at sendto() and can't be terminated |