Re: On login trigger: take three - Mailing list pgsql-hackers

From Robert Haas
Subject Re: On login trigger: take three
Date
Msg-id CA+TgmoZv9f1s797tihx-zXQN4AE4ZFBV5C0K=zngbgNu3xNNkg@mail.gmail.com
Whole thread Raw
In response to Re: On login trigger: take three  (Greg Nancarrow <gregn4422@gmail.com>)
List pgsql-hackers
On Tue, Feb 15, 2022 at 5:07 AM Greg Nancarrow <gregn4422@gmail.com> wrote:
> I've attached a re-based version (no functional changes from the
> previous) to fix cfbot failures.

I tried this:

rhaas=# create function on_login_proc() returns event_trigger as
$$begin perform pg_sleep(10000000); end$$ language plpgsql;
CREATE FUNCTION
rhaas=# create event trigger on_login_trigger on login execute
procedure on_login_proc();

When I then attempt to connect via psql, it hangs, as expected. When I
press ^C, psql exits, but the backend process is not cancelled and
just keeps chugging along in the background. The good news is that if
I connect to another database, I can cancel all of the hung sessions
using pg_cancel_backend(), and all of those processes then promptly
exit, and presumably I could accomplish the same thing by sending them
SIGINT directly. But it's still not great behavior. It would be easy
to use up a pile of connection slots inadvertently and have to go to
some trouble to get access to the server again. Since this is a psql
behavior and not a server behavior, one could argue that it's
unrelated to this patch, but in practice this patch seems to increase
the chances of people running into problems quite a lot.

-- 
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Melanie Plageman
Date:
Subject: Issue with pg_stat_subscription_stats
Next
From: Robert Haas
Date:
Subject: Re: Non-replayable WAL records through overflows and >MaxAllocSize lengths