Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1f99AV-0003V6-QU for pgsql-admin@arkaria.postgresql.org; Thu, 19 Apr 2018 13:00:08 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1f99AU-0001pR-PV for pgsql-admin@arkaria.postgresql.org; Thu, 19 Apr 2018 13:00:06 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1f99AT-0001p8-TB for pgsql-admin@lists.postgresql.org; Thu, 19 Apr 2018 13:00:06 +0000 Received: from resqmta-ch2-12v.sys.comcast.net ([2001:558:fe21:29:69:252:207:44]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1f99AQ-0003Rq-Cd for pgsql-admin@postgresql.org; Thu, 19 Apr 2018 13:00:04 +0000 Received: from resomta-ch2-13v.sys.comcast.net ([69.252.207.109]) by resqmta-ch2-12v.sys.comcast.net with ESMTP id 999YfWhsNxNju99ANfjv8V; Thu, 19 Apr 2018 12:59:59 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1524142799; bh=lz6gSA9bT63+ZvRMU78YYI25zozvxwGBHkk4vNK826Y=; h=Received:Received:Received:From:To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=QN6oVwm0BzmS9uX0lmMt7FRpJ8GrMTfcP5rV3U+lXZ/NWL7wC5bjW73FW1i9AgnhS dwBPBpWtNi19rNfZ+tA9V2cvejZ4QZJwLQRuSQ+mshrXigYglygKK9jEHMxMuo15QZ HKELnUmuyDWTUr1SnbufC3QJ0lUgx1oS3tZt03j2DXCgutCTT6/MNPLKkMxd/vaggC qRzLOD7B7KGMWz9XE2yMpbRdQ4F1pb1zFS/DCe8NJwaBotzATM06e+vfeUT73xS+ec ofczfqd6BbthGFpi+6MCKwIrZX7CJrOyZ/avrEmKkIwiMtj1MmH9x1kyzh9H5gfQ+J 5SAPTBXBFUkeg== Received: from jsievers.comcast.net ([12.187.116.132]) by resomta-ch2-13v.sys.comcast.net with SMTP id 99ACfVfKa6fYe99AEfESsn; Thu, 19 Apr 2018 12:59:57 +0000 Received: from jsievers.enova.com (localhost [127.0.0.1]) by jsievers.comcast.net (Postfix) with ESMTP id 3AE8F260056; Thu, 19 Apr 2018 07:59:48 -0500 (CDT) From: Jerry Sievers To: Wells Oliver Cc: pgsql-admin@postgresql.org Subject: Re: Never kill -9 postgres client processes on Linux... but why not? References: Date: Thu, 19 Apr 2018 08:59:48 -0400 In-Reply-To: (Wells Oliver's message of "Wed, 18 Apr 2018 21:40:46 -0700") Message-ID: <87po2vz70b.fsf@jsievers.enova.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-CMAE-Envelope: MS4wfFGnIUkbmEMNt7MvfVXTrEaSMlyTE0mmyxG1QPf4rTekONW0E67Z4pVCLF9rHO2Zc9S0iPxLB1lmmoNZu/QLf5Kt14UiW4S6FdzVIElYmxjC0g76vqIe +pMWw3BMTazrb+RwQ/NVgXXXUBW56hIN/NFPWoSBxv+WxVNDZj0tYXQpAbe4bSd/GiRyku74uLUWEN7oDhhL6FCM5fQu/CkWNeQQtxhE6+WEYFUadWBR3NYD List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Wells Oliver writes: > Had an issue tonight where I had a bunch of stalled queries from a > client connection and I just... could... not... kill... them. We > disconnected the client machine, turned it off, picked it up, shook > it around, yelled at it, and still these idle queries remained in > pg_stat_activity. Idle backends won't respond to a cancel since if they're "idle" there's nothing to cancel :-) If OTOH you tried pg_terminate_backend and this too drew no response, then you might have a case of backend blocked in a critical section such as SendV, symtomatic of a backend trying to write to a full pipe. HTH > > Then I did select pg_cancel_backend(pid) from pg_stat_activity where > client_addr = '..' and they just would... not... go.. away. > > So me being the big smart system administrator guy with shell access, > I logged in, and did a kill -9 xxx where xxx was the sme pid from the > pg_stat_activity result and... they finally went away! > > Felt good about myself until I realized, well, so did every other > connection, and in fact PG momentarily went into recovery mode. > > Everything was fine, but a) why is it a bad idea to kill -9 a client > PG process, but pg_cancel_backend() is OK-- and b) what to do about > stalled PG queries that won't die when you disconnect AND when you > pg_cancel_backend() them? > > Thanks! > > -- > Wells Oliver > wells.oliver@gmail.com > > -- Jerry Sievers Postgres DBA/Development Consulting e: postgres.consulting@comcast.net p: 312.241.7800