From: | "Sergey Konoplev" <gray(dot)ru(at)gmail(dot)com> |
---|---|
To: | "Martijn van Oosterhout" <kleptog(at)svana(dot)org>, "Sergey Konoplev" <gray(dot)ru(at)gmail(dot)com>, "Richard Huxton" <dev(at)archonet(dot)com>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: pg_cancel_backend() does not work with buzz queries |
Date: | 2007-10-23 11:53:06 |
Message-ID: | c3a7de1f0710230453h738de6eeh60802de1e35dd4b7@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-ru-general |
2007/10/23, Martijn van Oosterhout <kleptog(at)svana(dot)org>:
> On Tue, Oct 23, 2007 at 09:56:26AM +0400, Sergey Konoplev wrote:
> > I took a look at TCP state with netstat:
> >
> > pgdb:/base/PG-Data # netstat -pna |grep 8590
> > tcp 1 0 127.0.0.1:5432 127.0.0.1:35442
> > CLOSE_WAIT 8590/postgres: kono
>
> CLOSE_WAIT means that the client (in this case SSH) has shutdown() its
> end of the connection and evidently postgresql hasn't noticed. However,
> SSH has not closed its socket entirely, because then the write would
> fail.
>
> Can you strace the SSH daemon, my bet is that it's also stuck on a
> write(), to the original client. It would also be interesting to know
> what the original client is doing, since it's obviously still alive.
> Looks like somewhere along the chain a program called shutdown() but is
> no longer reading incoming data...
>
> Hope this helps,
I've done strace and noticed that this SHH daemon is repeating next output:
pid 10511 stopped, [SIGTRAP]
10.485688 [ffffe410] rt_sigprocmask(SIG_BLOCK, [CHLD],
[wait(0x57f) = 10511]
pid 10511 stopped, [SIGTRAP]
[], 8) = 0
[wait(0x57f) = 10511]
pid 10511 stopped, [SIGTRAP]
0.000578 [ffffe410] rt_sigprocmask(SIG_SETMASK, [], [wait(0x57f) = 10511]
pid 10511 stopped, [SIGTRAP]
NULL, 8) = 0
[wait(0x57f) = 10511]
pid 10511 stopped, [SIGTRAP]
0.000468 [ffffe410] read(4, [wait(0x57f) = 10511]
pid 10511 stopped, [SIGTRAP]
"\x0e\xd7\x62\xdb\xc8\x97\xbb\xbc\x52\xe6\xe1\xab\x6a\xcc"..., 16384) = 32
[wait(0x57f) = 10511]
pid 10511 stopped, [SIGTRAP]
0.000533 [ffffe410] select(25, [4 5 19 21 22], [22], NULL, NULL
[wait(0x57f) = 10511]
pid 10511 stopped, [SIGTRAP]
) = 1 (out [22])
[wait(0x57f) = 10511]
pid 10511 stopped, [SIGTRAP]
0.000705 [ffffe410] rt_sigprocmask(SIG_BLOCK, [CHLD],
[wait(0x57f) = 10511]
pid 10511 stopped, [SIGTRAP]
[], 8) = 0
[wait(0x57f) = 10511]
pid 10511 stopped, [SIGTRAP]
0.000481 [ffffe410] rt_sigprocmask(SIG_SETMASK, [], [wait(0x57f) = 10511]
pid 10511 stopped, [SIGTRAP]
NULL, 8) = 0
[wait(0x57f) = 10511]
pid 10511 stopped, [SIGTRAP]
0.000447 [ffffe410] write(22,
"\x51\x00\x00\x00\x11\x53\x65\x6c\x65\x63\x74\x20\x27\x4f"..., 18
[wait(0x57f) = 10511]
pid 10511 stopped, [SIGTRAP]
) = 18
[wait(0x57f) = 10511]
pid 10511 stopped, [SIGTRAP]
0.000876 [ffffe410] select(25, [4 5 19 21 22], [], NULL, NULL
[wait(0x57f) = 10511]
pid 10511 stopped, [SIGTRAP]
) = 1 (in [22])
[wait(0x57f) = 10511]
Original client was interrupted by me before the backend has hung and
I've found neither its process (in task manager) nor corresponding
netstat output line.
By the way, I've also noticed that the SSH daemon's (which is in
FIN_WAIT2) timer is "off" and took a look at tcp_fin_timeout...
pgdb:~ # netstat -pnao |grep 37465
tcp 1 131072 127.0.0.1:5432 127.0.0.1:37465
CLOSE_WAIT 24855/postgres: kon unkn-4 (41.30/0/0)
tcp 73728 0 127.0.0.1:37465 127.0.0.1:5432
FIN_WAIT2 10511/sshd: dcsshcl off (0.00/0/0)
pgdb:~ # cat /proc/sys/net/ipv4/tcp_fin_timeout
60
...which is 60. I wonder are there another variables which affect on
FIN_WAIT2 timeout?
--
Regards,
Sergey Konoplev
From | Date | Subject | |
---|---|---|---|
Next Message | Marc Schablewski | 2007-10-23 11:58:25 | Reliability of WAL replication |
Previous Message | yogesh | 2007-10-23 11:03:23 | Postgres SQL Client for Suse Linux |
From | Date | Subject | |
---|---|---|---|
Next Message | Sergey Konoplev | 2007-10-24 05:40:48 | Fwd: Fwd: pg_cancel_backend() не снимает зависшие транзакции |
Previous Message | Martijn van Oosterhout | 2007-10-23 07:35:04 | Re: pg_cancel_backend() does not work with buzz queries |