st 16. 12. 2020 v 20:38 odesÃlatel Pavel Stehule <pavel.steh...@gmail.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 >> >>
