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@xxxxxxxxx> wrote:
>
>> On 10 Oct 2016, at 21:28, Alban Hertroys <haramrae@xxxxxxxxx> wrote:
>>
>>
>>> On 10 Oct 2016, at 21:12, Periko Support <pheriko.support@xxxxxxxxx> 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@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
