Re: On login trigger: take three

st 16. 12. 2020 v 20:38 odesílatel Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
napsal:

> Attached please find new versoin of the patch based on
> on_connect_event_trigger_WITH_SUGGESTED_UPDATES.patch
>
>> So there is still only "disable_client_connection_trigger" GUC? because
>> we need possibility to disable client connect triggers and there is no such
>> need for other event types.
>>
>> As you suggested have added "dathaslogontriggers" flag which is set when
>> client connection trigger is created.
>> This flag is never cleaned (to avoid visibility issues mentioned in my
>> previous mail).
>>
>
> This is much better - I don't see any slowdown when logon trigger is not
> defined
>
> I did some benchmarks and looks so starting language handler is relatively
> expensive - it is about 25% and starting handler like event trigger has
> about 35%. But this problem can be solved later and elsewhere.
>
> I prefer the inverse form of disable_connection_trigger. Almost all GUC
> are in positive form - so enable_connection_triggger is better
>
> I don't think so current handling dathaslogontriggers is good for
> production usage. The protection against race condition can be solved by
> lock on pg_event_trigger
>

I thought about it, and probably the counter of connect triggers will be
better there. The implementation will be simpler and more robust.

Pavel

> Regards
>
> Pavel
>
>
>
>>
>>
>> --
>> Konstantin Knizhnik
>> Postgres Professional: http://www.postgrespro.com
>> The Russian Postgres Company
>>
>>