Re: pg_terminate_backend() issues

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: pg_terminate_backend() issues
Дата
Msg-id 8235.1208358339@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: pg_terminate_backend() issues  (Gregory Stark <stark@enterprisedb.com>)
Ответы Re: pg_terminate_backend() issues  (Gregory Stark <stark@enterprisedb.com>)
Список pgsql-hackers
Gregory Stark <stark@enterprisedb.com> writes:
> "Tom Lane" <tgl@sss.pgh.pa.us> writes:
>> No, we wouldn't, because a SIGTERM can only actually fire at a
>> CHECK_FOR_INTERRUPTS() call.  You'd just need to be sure there wasn't
>> one in the cleanup code.

> Wait, huh? In that case I don't see what advantage any of this has over
> Bruce's patch. And his approach seemed a lot more robust.

Maybe I missed something, but I thought he was just proposing some
macro syntactic sugar over the same code that I described.

I'm not against syntactic sugar, but it doesn't seem to be totally
clean; I think you would need two repetitions of the function and
arg anyway:
PG_ENSURE_ERROR_CLEANUP(cleanup_function, arg);{    ... risky code here
...}PG_END_ENSURE_ERROR_CLEANUP(cleanup_function,arg);
 

because both the "before" and "after" parts need to know the function
name and the arg to pass it.  The only way to avoid duplication would be
if the whole controlled code block was actually an argument to the
macro:
PG_ENSURE_ERROR_CLEANUP(cleanup_function, arg,    ... risky code here ...);

but there are very good reasons not to do that when the controlled
code can be large; for instance that #if can't be used portably
in a macro argument.
        regards, tom lane


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

Предыдущее
От: Gregory Stark
Дата:
Сообщение: Re: pg_terminate_backend() issues
Следующее
От: Gregory Stark
Дата:
Сообщение: Re: pg_terminate_backend() issues