Re: On login trigger: take three

From: Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: On login trigger: take three
Date: 2020-09-14 14:12:42
Message-ID: 5706c7f5-98cd-bc20-cf1e-dd3f363e2c99@postgrespro.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 14.09.2020 12:44, Pavel Stehule wrote:
> Hi
>
> I am checking last patch, and there are notices
>
> 1. disable_session_start_trigger should be SU_BACKEND instead SUSET
>
> 2. The documentation should be enhanced - there is not any note about
> behave when there are unhandled exceptions, about motivation for this
> event trigger
>
> 3. regress tests should be enhanced - the cases with exceptions are
> not tested
>
> 4. This trigger is not executed again after RESET ALL or DISCARD ALL -
> it can be a problem if somebody wants to use this trigger for
> initialisation of some session objects with some pooling solutions.
>
> 5. The handling errors don't work well for canceling. If event trigger
> waits for some event, then cancel disallow connect although connected
> user is superuser
>
> CREATE OR REPLACE FUNCTION on_login_proc2() RETURNS EVENT_TRIGGER AS
> $$ begin perform pg_sleep(10000); raise notice '%', fx1(100);raise
> notice 'kuku kuku'; end  $$ language plpgsql;
>
> probably nobody will use pg_sleep in this routine, but there can be
> wait on some locks ...
>
> Regards
>
> Pavel
>
>
>

Hi
Thank you very much for looking at my patch for connection triggers.
I have fixed 1-3 issues in the attached patch.
Concerning 4 and 5 I have some doubts:

4. Should I add some extra GUC to allow firing of session_start trigger
in case of  RESET ALL or DISCARD ALL ?
Looks like such behavior contradicts with event name "session_start"...
And do we really need it? If some pooler is using RESET ALL/DISCARD ALL
to emulate session semantic then  most likely it provides way to define
custom actions which
should be perform for session initialization. As far as I know, for
example pgbouncer allows do define own on-connect hooks.

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?

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

Attachment Content-Type Size
on_connect_event_trigger-7.patch text/x-patch 16.5 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2020-09-14 14:17:28 Re: pg_restore causing deadlocks on partitioned tables
Previous Message Daniel Gustafsson 2020-09-14 13:53:01 Re: Fix overflow at return wchar2char (src/backend/utils/adt/pg_locale.c)