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 1f93bc-0005tG-5f for pgsql-admin@arkaria.postgresql.org; Thu, 19 Apr 2018 07:03:44 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1f93ba-0008Nz-3O for pgsql-admin@arkaria.postgresql.org; Thu, 19 Apr 2018 07:03:42 +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 1f93bZ-0008K9-9i for pgsql-admin@lists.postgresql.org; Thu, 19 Apr 2018 07:03:41 +0000 Received: from mail-oi0-x22e.google.com ([2607:f8b0:4003:c06::22e]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1f93bV-0003Ki-VZ for pgsql-admin@lists.postgresql.org; Thu, 19 Apr 2018 07:03:39 +0000 Received: by mail-oi0-x22e.google.com with SMTP id j10-v6so3913088oii.12 for ; Thu, 19 Apr 2018 00:03:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=Pw+KRsXYTlxqW88zZqtmX0GJxDSe2RJQtDAn2IP2Oak=; b=J1wR+v6dFeK3t0e9ULya5TeyzNht2dJKz1/SQEkl90OTBeGJI3UdHNMMA08exgQ9nu vUD6TG/bpYMUcKHvrteZ4Po+sUFxCdmw4ygOLi41gvMYaLC2PsHaf0gi1igYA+k4KDqg 7ymotuzSqtiL/Cdrl/r79wgWYIHlDR1RDrfOOVuWpHSEbHcKI9NXxLkvblYUV4Ob1WhW VdS+bm5oq1Utp29j3LXQN+eOxHZMvDp8QtsKyyHPeCaTBq/gcXD5CPYrUxF5ykC20vjq PeYu668LuXuRh7CkhZAMvKZ7dVdYX5mGZlUC0Fz8EmBl2yahEj+Vd8MLfOqBZEmCKhBz iEjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=Pw+KRsXYTlxqW88zZqtmX0GJxDSe2RJQtDAn2IP2Oak=; b=AByvVzuG1TVvX7Dpi2LEa/w1lhN9S9VKIniGPNnJXAMC7Ls2sdqm0z49wLpfq69Gj2 WRK7DMW0A5hWmKL6p808eKp3ihUgnhLOPBJmCeVu7glBeXBbBOT/m2oZDQJd3FKrrw80 r7mUxZY2EyxX0YpsFr6yWNLXyq/Kwaa+IBycbX4kT2mdPY3u1GgAfimDOOrw/ZbQSjr+ hXWM0TMwyNGyIDnomRxiKc8wro6z8OvIOQr8/k/rskd4+h/xWFzg0ShpvCOGGxm8TySL 7Nsj+j9ZsqXW/nL53qPbEpSNhEC1GiMcayGbWjohR6qhpt1kpqOlGO0Fd/l07BT1E0ls syRQ== X-Gm-Message-State: ALQs6tD+jWQuXX4BFLh/cb2sHFkCiZXhr+A7M6QGg9L3msCtToBDIrL9 C1DWqHkQUUOsH3qT9UAh7tHdOw== X-Google-Smtp-Source: AIpwx4+pT9R33/fx458XwlpeCNiAsiii+dvopiaJqDELoES2tLGnEL9madzX+dGE4oJrNqfs5LMglw== X-Received: by 2002:aca:f141:: with SMTP id p62-v6mr3091570oih.56.1524121416284; Thu, 19 Apr 2018 00:03:36 -0700 (PDT) Received: from [192.168.1.10] (ip70-171-116-89.no.no.cox.net. [70.171.116.89]) by smtp.googlemail.com with ESMTPSA id r12-v6sm2395231otr.27.2018.04.19.00.03.34 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Apr 2018 00:03:35 -0700 (PDT) Subject: Re: Never kill -9 postgres client processes on Linux... but why not? To: pgsql-admin@lists.postgresql.org References: <57d6f3fa-3d9f-9dda-f2a2-131966b5f407@catalyst.net.nz> From: Ron Message-ID: <418d6fe1-a96a-9299-f173-09a804d0b7b3@gmail.com> Date: Thu, 19 Apr 2018 02:03:33 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <57d6f3fa-3d9f-9dda-f2a2-131966b5f407@catalyst.net.nz> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 04/18/2018 11:53 PM, Mark Kirkwood wrote: > Hi, > > > On 19/04/18 16:40, Wells Oliver wrote: >> 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. >> >> 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? >> > > Did you try pg_terminate_backend? I'm guessing that might not have worked > either...but is worth it trying before belting them with kill -9! +1 to pg_terminate_backend.  On the rare occasion pg_cancel_backend doesn't work, I hit the pid with pg_terminate_backend, and that always works. -- Angular momentum makes the world go 'round.