Re: On login trigger: take three - Mailing list pgsql-hackers

From Masahiko Sawada
Subject Re: On login trigger: take three
Date
Msg-id CAD21AoDHLFOyBdA8SymiD-eW2a5vOMSO165B_TOFvtbihnO15g@mail.gmail.com
Whole thread Raw
In response to Re: On login trigger: take three  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: On login trigger: take three
List pgsql-hackers
On Sat, Dec 26, 2020 at 4:04 PM Pavel Stehule <pavel.stehule@gmail.com> wrote:
>
>
>
> so 26. 12. 2020 v 8:00 odesílatel Pavel Stehule <pavel.stehule@gmail.com> napsal:
>>
>> Hi
>>
>>
>>> Thank you.
>>> I have applied all your fixes in on_connect_event_trigger-12.patch.
>>>
>>> Concerning enable_client_connection_trigger GUC, I think that it is really useful: it is the fastest and simplest
wayto disable login triggers in case 
>>> of some problems with them (not only for superuser itself, but for all users). Yes, it can be also done using
"ALTEREVENT TRIGGER DISABLE". 
>>> But assume that you have a lot of databases with different login policies enforced by on-login event triggers. And
youwant temporary disable them all, for example for testing purposes. 
>>> In this case GUC is most convenient way to do it.
>>>
>>
>> There was typo in patch
>>
>> diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
>> index f810789..8861f1b 100644
>> --- a/doc/src/sgml/config.sgml
>> +++ b/doc/src/sgml/config.sgml
>> @@ -1,4 +1,4 @@
>> -<!-- doc/src/sgml/config.sgml -->
>> +\<!-- doc/src/sgml/config.sgml -->
>>
>> I have not any objections against functionality or design. I tested the performance, and there are no negative
impactswhen this feature is not used. There is significant overhead related to plpgsql runtime initialization, but when
thistrigger will be used, then probably some other PLpgSQL procedures and functions will be used too, and then this
overheadcan be ignored. 
>>
>> * make without warnings
>> * make check-world passed
>> * doc build passed
>>
>> Possible ToDo:
>>
>> The documentation can contain a note so usage connect triggers in environments with short life sessions and very
shortfast queries without usage PLpgSQL functions or procedures can have negative impact on performance due overhead of
initializationof PLpgSQL engine. 
>>
>> I'll mark this patch as ready for committers
>
>
> looks so this patch has not entry in commitfestapp 2021-01
>

Yeah, please register this patch before the next CommitFest[1] starts,
2021-01-01 AoE[2].

Regards,

[1] https://commitfest.postgresql.org/31/
[2] https://en.wikipedia.org/wiki/Anywhere_on_Earth

--
Masahiko Sawada
EnterpriseDB:  https://www.enterprisedb.com/



pgsql-hackers by date:

Previous
From: Bharath Rupireddy
Date:
Subject: Re: Parallel Inserts in CREATE TABLE AS
Next
From: Bharath Rupireddy
Date:
Subject: Re: EXPLAIN/EXPLAIN ANALYZE REFRESH MATERIALIZED VIEW