Re: elog(FATAL) vs shared memory

Поиск
Список
Период
Сортировка
От Jim Nasby
Тема Re: elog(FATAL) vs shared memory
Дата
Msg-id 0A70AFA3-BEE1-4215-AA32-523E8928EFBD@decibel.org
обсуждение исходный текст
Ответ на Re: elog(FATAL) vs shared memory  (Stuart Bishop <stuart.bishop@canonical.com>)
Ответы Re: elog(FATAL) vs shared memory  (Jim Nasby <decibel@decibel.org>)
Список pgsql-hackers
FWIW, you might want to put some safeguards in there so that you  
don't try to inadvertently kill the backend that's running that  
function... unfortunately I don't think there's a built-in function  
to tell you the PID of the backend you're connected to; if you're  
connecting via TCP you could use inet_client_addr() and  
inet_client_port(), but that won't work if you're using the socket to  
connect.

On Apr 5, 2007, at 6:23 AM, Stuart Bishop wrote:

> Mark Shuttleworth wrote:
>> Tom Lane wrote:
>>> (1) something (still not sure what --- Martin and Mark, I'd  
>>> really like
>>> to know) was issuing random SIGTERMs to various postgres processes
>>> including autovacuum.
>>>
>>
>> This may be a misfeature in our test harness - I'll ask Stuart  
>> Bishop to
>> comment.
>
> After a test is run, the test harness kills any outstanding  
> connections so
> we can drop the test database. Without this, a failing test could  
> leave open
> connections dangling causing the drop database to block.
>
> CREATE OR REPLACE FUNCTION _killall_backends(text)
> RETURNS Boolean AS $$
>     import os
>     from signal import SIGTERM
>
>     plan = plpy.prepare(
>         "SELECT procpid FROM pg_stat_activity WHERE datname=$1",  
> ['text']
>         )
>     success = True
>     for row in plpy.execute(plan, args):
>         try:
>             plpy.info("Killing %d" % row['procpid'])
>             os.kill(row['procpid'], SIGTERM)
>         except OSError:
>             success = False
>
>     return success
> $$ LANGUAGE plpythonu;
>
> -- 
> Stuart Bishop <stuart.bishop@canonical.com>   http:// 
> www.canonical.com/
> Canonical Ltd.                                http://www.ubuntu.com/
>

--
Jim Nasby                                            jim@nasby.net
EnterpriseDB      http://enterprisedb.com      512.569.9461 (cell)




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Jim Nasby
Дата:
Сообщение: Re: Eliminating unnecessary left joins
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: Vista/IPv6