Re: [HACKERS] PoC: custom signal handler for extensions - Mailing list pgsql-hackers

From Andrey Lepikhov
Subject Re: [HACKERS] PoC: custom signal handler for extensions
Date
Msg-id 8ee2ae87-25d9-16d5-4d67-dd81f4c3328c@postgrespro.ru
Whole thread Raw
In response to Re: [HACKERS] PoC: custom signal handler for extensions  (Teodor Sigaev <teodor@sigaev.ru>)
List pgsql-hackers
On 1/12/18 20:51, Teodor Sigaev wrote:
>> In perspective, this mechanism provides the low-level instrument to 
>> define remote procedure call on extension side. The simple RPC that 
>> defines effective userid on remote backend (remote_effective_user 
>> function) is attached for example.
> 7) Suppose, API allows to use different handlers in different processes 
> for the same reason, it's could be reason of confusion. I suggest to 
> restrict Register/Unregister call only for shared_preload_library, ie 
> only during startup.
+1
> 
> 8) I'd like to see an example of usage this API somewhere in contrib in 
> exsting modules. Ideas?
I imagine, auto_explain could demonstrate usage of the API by 
implementing logging of current query state, triggered by a signal. Most 
of necessary code is already existed there.
Of course, this option will be enabled if auto_explain loads on startup.
But, maybe it breaks main concept of the auto_explain extension?

-- 
Regards
Andrey Lepikhov
Postgres Professional




pgsql-hackers by date:

Previous
From: Kyotaro Horiguchi
Date:
Subject: Re: test_decoding assertion failure for the loss of top-sub transaction relationship
Next
From: Noah Misch
Date:
Subject: Re: Bug: Reading from single byte character column type may cause out of bounds memory reads.