Re: dropdb --force

čt 19. 9. 2019 v 13:52 odesílatel vignesh C <vignesh21(at)gmail(dot)com> napsal:

> On Thu, Sep 19, 2019 at 12:14 AM Pavel Stehule <pavel(dot)stehule(at)gmail(dot)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(at)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
>