Re: On login trigger: take three
| От | Robert Haas |
|---|---|
| Тема | Re: On login trigger: take three |
| Дата | |
| Msg-id | CA+TgmoZv9f1s797tihx-zXQN4AE4ZFBV5C0K=zngbgNu3xNNkg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: On login trigger: take three (Greg Nancarrow <gregn4422@gmail.com>) |
| Список | 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 по дате отправления: