From: Rural Hunter <ruralhunter@gmail.com>
Message-ID: <53DF5C93.6010007@gmail.com>
Date: Mon, 04 Aug 2014 18:12:35 +0800
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
 rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: "pgsql-performance@postgresql.org" <pgsql-performance@postgresql.org>
Subject: Re: Very slow planning performance on partition table
References: <53CFB6BC.4050606@gmail.com>	<25010.1406253203@sss.pgh.pa.us>
	<53D26875.2080604@gmail.com>	<53D51E49.102@gmail.com>
	<24564.1406478487@sss.pgh.pa.us>
	<CAMkU=1ydmpt9XRMxt0sPNnQsXEoF_c7bgp2kHxtDbPNGg5Vj5w@mail.gmail.com>
	<53D7597E.2080209@gmail.com>
 <CAMkU=1wHC_w6D2kc1V6y1PDkRxDV3B+1fJBk3Z2L=SprGw7omw@mail.gmail.com>
 <53D8C2F2.3080105@gmail.com>
In-Reply-To: <53D8C2F2.3080105@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org

在 2014/7/30 18:03, Rural Hunter 写道:
> I think I understand what happened now. I have another monitor script 
> runs periodically and calls pg_cancel_backend and pg_terminate_backend 
> for those hanging update sqls. However for some unkown reason the 
> cancle and termiante command doesn't work at pgsql side for those 
> update sqls.
>
With the log of the monitor&kill scipt, I can confirm that the 
CLOSE_WAIT is not caused by it. I logged the netstat before actually 
doing the kill and found the CLOSE_WAIT connections were already there. 
So it must be something else caused the CLOSE_WAIT connections.


-- 
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance