Re: pg_cancel_backend() does not work with buzz queries

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

In response to

Browse pgsql-general by date

  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

Browse pgsql-ru-general by date

  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