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