Hello!
On 11.01.2018 18:53, Arthur Zakirov wrote:
The relationship between custom signals and
assigned handlers (function addresses) is replicated from postmaster to
child processes including working backends.
I think this happens only if a custom signal registered during initializing
shared_preload_libraries.
But from RegisterCustomProcSignalHandler()'s implementation I see that you can
register the signal anytime. Am I wrong?
If so then custom signal handlers may not work as expected.
Yeah, thanks. Added checks on
process_shared_preload_libraries_in_progress flag.
What is purpose of AssignCustomProcSignalHandler() function? This function can
erase a handler set by another extension.
For example, extension 1 set handler passing reason PROCSIG_CUSTOM_1, and
extension 2 set another handler passing reason PROCSIG_CUSTOM_1 too. Here the
handler of the extension 2 will be purged.
+
+ Assert(reason >= PROCSIG_CUSTOM_1 && reason <= PROCSIG_CUSTOM_N);
+
I think it is not good to use asserts within AssignCustomProcSignalHandler()
and GetCustomProcSignalHandler(). Because this functions can be executed by an
external extension, and it may pass a reason outside this boundary. It will be
better if the reason will be checked in runtime.
I was guided by the consideration that assertions define preconditions
for input parameter (in our case, procsignal) of functions. Meeting
these preconditions have to be provided by function callers. Since these
checks is not expensive it will be good to replace their to ereport calls.
Updated patch is attached in [1].
1.
https://www.postgresql.org/message-id/37a48ac6-aa14-4e36-5f08-cf8581fe1382%40gmail.com
--
Regards,
Maksim Milyutin
