On Thu, Sep 19, 2019 at 11:41 PM Pavel Stehule <pavel.steh...@gmail.com> wrote: > > > > čt 19. 9. 2019 v 13:52 odesílatel vignesh C <vignes...@gmail.com> napsal: >> >> 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? > > > I agree so it's not nice behave. Again there are two possible solutions > > 1. strategy - owner can all - and don't check rigts > 2. implement own check of rights instead using checks from > pg_terminate_backend. > > It's easy fixable when we find a agreement what is preferred behave. > > Pavel > For the above I felt, if we could identify if we don't have permissions to terminate any of the connected session, throwing the error at that point would be appropriate.
Regards, Vignesh EnterpriseDB: http://www.enterprisedb.com
