Re: psql 9.3 automatic recovery in progress

From: Periko Support <pheriko(dot)support(at)gmail(dot)com>
To: pgsql-general(at)postgresql(dot)org
Subject: Re: psql 9.3 automatic recovery in progress
Date: 2016-10-10 19:38:23
Message-ID: CAK2yrTbsE+K0yVekvCicCg=Rj8OmD0GMUSfmL3YmjDfKdvMsXA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

That script was from a vendor called 'allianzgrp.com'.

Was their solution.

Them I have a lot of work to do here.

On Mon, Oct 10, 2016 at 12:32 PM, Alban Hertroys <haramrae(at)gmail(dot)com> wrote:
>
>> On 10 Oct 2016, at 21:28, Alban Hertroys <haramrae(at)gmail(dot)com> wrote:
>>
>>
>>> On 10 Oct 2016, at 21:12, Periko Support <pheriko(dot)support(at)gmail(dot)com> wrote:
>>>
>>> for pid in idle_record:
>>> try:
>>> # print "process details",pid
>>> # os.system("kill -9 %s" % (int(pid[0]), ))
>>> os.kill(int(pid[0]), signal.SIGKILL)
>>> except OSError as ex:
>>> continue
>>
>> That query returns PostgreSQL backends and you're sending them SIGKILL. Not a recommended practice far as I know. Shouldn't you rather be sending those kill signals to the clients connecting to the db?
>> Worse, apparently at some time in the past (a month ago matching those logs, perhaps?) it used to send kill -9! That's absolutely a very bad idea.
>>
>> While on the topic, there is a PG function to cancel a backend query from within PG: https://www.postgresql.org/docs/9.5/static/functions-admin.html
>> I think that's the best way to go about this, and best of all, you can combine that with your select statement.
>
> Another idea struck me; if that script is under version control, you can check when that change was committed. If it isn't, perhaps you should. My current favourite is Hg (aka Mercurial), which happens to be written in Python, just like your script.
>
> Alban Hertroys
> --
> If you can't see the forest for the trees,
> cut the trees and you'll find there is no forest.
>

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Periko Support 2016-10-10 19:43:56 Re: psql 9.3 automatic recovery in progress
Previous Message Alban Hertroys 2016-10-10 19:32:49 Re: psql 9.3 automatic recovery in progress