On Thu, Sep 19, 2019 at 12:14 AM Pavel Stehule <pavel.steh...@gmail.com> wrote: > > Hi > > I am sending updated version - the changes against last patch are two. I use > pg_terminate_backed for killing other terminates like Tom proposed. I am not > sure if it is 100% practical - on second hand the necessary right to kill > other sessions is almost available - and consistency with > pg_terminal_backend has sense. More - native implementation is significantly > better then solution implemented outer. I fixed docs little bit - the timeout > for logout (as reaction on SIGTERM is only 5 sec). > > Regards > > Pavel > > I observed one thing with the latest patch: There is a possibility that in case of drop database failure some sessions may be terminated.
It can happen in the following scenario: 1) create database test; /* super user creates test database */ 2) create user test password 'test@123'; /* super user creates test user */ 3) alter user test nosuperuser; /* super user changes test use to non super user */ 4) alter database test owner to test; /* super user set test as test database owner */ 5) psql -d test /* connect to test database as super user - Session 1 */ 6) psql -d postgres -U test /* connect to test database as test user - Session 2 */ 7) psql -d postgres -U test /* connect to test database as test user - Session 3 */ 8) drop database (force) test; /* Executed from Session 3 */ Drop database fails in Session 3 with: ERROR: must be a superuser to terminate superuser process Session 2 is terminated, Session 1 is left as it is. Is the above behaviour ok to terminate session 2 in case of drop database failure? Thoughts? Regards, Vignesh EnterpriseDB: http://www.enterprisedb.com
