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 <haram...@gmail.com> wrote:
>
>> On 10 Oct 2016, at 21:28, Alban Hertroys <haram...@gmail.com> wrote:
>>
>>
>>> On 10 Oct 2016, at 21:12, Periko Support <pheriko.supp...@gmail.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.
>
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
