Re: dropdb --force

st 18. 9. 2019 v 19:11 odesílatel vignesh C <vignesh21@gmail.com> napsal:

> On Wed, Sep 18, 2019 at 9:41 AM Pavel Stehule <pavel.stehule@gmail.com>
> wrote:
> >
> >
> >
> > st 18. 9. 2019 v 5:59 odesílatel vignesh C <vignesh21@gmail.com> napsal:
> >>
> >> On Wed, Sep 18, 2019 at 8:30 AM Pavel Stehule <pavel.stehule@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
>