č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 > Regards, > Vignesh > EnterpriseDB: http://www.enterprisedb.com >
