st 18. 9. 2019 v 19:11 odesÃlatel vignesh C <vignes...@gmail.com> napsal:
> On Wed, Sep 18, 2019 at 9:41 AM Pavel Stehule <pavel.steh...@gmail.com> > wrote: > > > > > > > > st 18. 9. 2019 v 5:59 odesÃlatel vignesh C <vignes...@gmail.com> napsal: > >> > >> On Wed, Sep 18, 2019 at 8:30 AM Pavel Stehule <pavel.steh...@gmail.com> > wrote: > >> > > >> > > >> Hi Pavel, > >> > >> One Comment: > >> In the documentation we say drop database will fail after 60 seconds > >> <varlistentry> > >> <term><literal>FORCE</literal></term> > >> <listitem> > >> <para> > >> Attempt to terminate all existing connections to the target > database. > >> </para> > >> <para> > >> This will fail, if current user has no permissions to terminate > other > >> connections. Required permissions are the same as with > >> <literal>pg_terminate_backend</literal>, described > >> in <xref linkend="functions-admin-signal"/>. > >> > >> This will also fail, if the connections do not terminate in 60 > seconds. > >> </para> > >> </listitem> > >> </varlistentry> > > > > > > This is not valid. With FORCE flag the clients are closed immediately > > > >> > >> > >> But in TerminateOtherDBBackends: > >> foreach (lc, pids) > >> + { > >> + int pid = lfirst_int(lc); > >> + > >> + (void) kill(pid, SIGTERM); /* ignore any error */ > >> + } > >> + > >> + /* sleep 100ms */ > >> + pg_usleep(100 * 1000L); > >> + } > >> > >> We check for any connected backends after sending kill signal in > >> CountOtherDBBackends and throw error immediately. > >> > >> I had also tested this scenario to get the following error immediately: > >> test=# drop database (force) test1; > >> ERROR: database "test1" is being accessed by other users > >> DETAIL: There is 1 other session using the database. > >> > > > > sure - you cannot to kill self > > > This was not a case where we try to do drop database from the same > session, I got this error when one of the process took longer time to > terminate the other connected process. > But this scenario was simulated using gdb, I'm not sure if similar > scenario is possible without gdb in production environment. If > terminating process does not happen immediately then the above > scenario can happen. > maybe - gdb can handle SIGTERM signal. I think so current design should be ok, because it immediately send SIGTERM signals and then try to check 5 sec if these signals are really processed. If not, then it raise error, and do nothing. Pavel > Regards, > Vignesh > EnterpriseDB: http://www.enterprisedb.com >