Re: pg_terminate_backend() issues - Mailing list pgsql-hackers

From Tom Lane
Subject Re: pg_terminate_backend() issues
Date
Msg-id 8235.1208358339@sss.pgh.pa.us
Whole thread Raw
In response to Re: pg_terminate_backend() issues  (Gregory Stark <stark@enterprisedb.com>)
Responses Re: pg_terminate_backend() issues  (Gregory Stark <stark@enterprisedb.com>)
List 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 by date:

Previous
From: Gregory Stark
Date:
Subject: Re: pg_terminate_backend() issues
Next
From: Gregory Stark
Date:
Subject: Re: pg_terminate_backend() issues