Re: On login trigger: take three

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
>
>