po 14. 9. 2020 v 17:53 odesÃlatel Konstantin Knizhnik < k.knizh...@postgrespro.ru> napsal:
> > > On 14.09.2020 17:34, Pavel Stehule wrote: > > If we introduce buildin session trigger , we should to define what is the > session. Your design is much more related to the process than to session. > So the correct name should be "process_start" trigger, or some should be > different. I think there are two different events - process_start, and > session_start, and there should be two different event triggers. Maybe the > name "session_start" is just ambiguous and should be used with a different > name. > > > I agree. > I can rename trigger to backend_start or process_start or whatever else. > Creating a good name can be hard - it is not called for any process - so maybe "user_backend_start" ? > > >> >> 5. I do not quite understand your concern. If I define trigger >> procedure which is blocked (for example as in your example), then I can >> use pg_cancel_backend to interrupt execution of login trigger and >> superuser can login. What should be changed here? >> > > You cannot run pg_cancel_backend, because you cannot open a new session. > There is a cycle. > > > It is always possible to login by disabling startup triggers using > disable_session_start_trigger GUC: > > psql "dbname=postgres options='-c disable_session_start_trigger=true'" > sure, I know. Just this behavior can be a very unpleasant surprise, and my question is if it can be fixed. Creating custom libpq variables can be the stop for people that use pgAdmin.
