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 Regards Pavel > > > -- > Konstantin Knizhnik > Postgres Professional: http://www.postgrespro.com > The Russian Postgres Company > >
