From: | vignesh C <vignesh21(at)gmail(dot)com> |
---|---|
To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
Cc: | Ryan Lambert <ryan(at)rustprooflabs(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Anthony Nowocien <anowocien(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Filip Rembiałkowski <filip(dot)rembialkowski(at)gmail(dot)com> |
Subject: | Re: dropdb --force |
Date: | 2019-09-19 11:51:48 |
Message-ID: | CALDaNm06Qp+tYU=wy9aFY3bT+cM+eftFkN9v1wE70LBJ3R6G+Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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?
Regards,
Vignesh
EnterpriseDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Asim R P | 2019-09-19 11:59:59 | Re: standby recovery fails (tablespace related) (tentative patch and discussion) |
Previous Message | Kuntal Ghosh | 2019-09-19 11:50:15 | Re: subscriptionCheck failures on nightjar |