From: | Zhihong Yu <zyu(at)yugabyte(dot)com> |
---|---|
To: | Julien Rouhaud <rjuju123(at)gmail(dot)com> |
Cc: | Euler Taveira <euler(at)eulerto(dot)com>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: including pid's for `There are XX other sessions using the database` |
Date: | 2022-08-21 14:05:52 |
Message-ID: | CALNJ-vT5RcaEF5JJn3a7pDnuEjcUvb+D+2Y+Q98K1kLePY4LpA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, Aug 21, 2022 at 6:39 AM Julien Rouhaud <rjuju123(at)gmail(dot)com> wrote:
> Hi,
>
> On Sat, Aug 20, 2022 at 02:52:29AM -0700, Zhihong Yu wrote:
> > On Fri, Aug 19, 2022 at 9:31 PM Euler Taveira <euler(at)eulerto(dot)com> wrote:
> >
> > >
> > Thanks for responding.
> >
> > Since pg_stat_activity shows fewer number of connections compared to the
> > number revealed in the error message,
> > I am not sure the above query would terminate all connections for the
> > database to be dropped.
>
> How exactly are you checking pg_stat_activity? If you query that view
> right
> after a failed attempt at dropping a database, there's no guarantee to
> find the
> exact same connections on the target database as client might connect or
> disconnect.
>
> If you prevent any further connection by e.g. tweaking the pg_hba.conf
> then you
> have a guarantee that the query will terminate all conflicting connections.
> Using the FORCE option is just a simpler way to do it, as dropdb() starts
> with
> preventing any new connection on the target database.
>
> Overall, I agree that adding the list of pid to the message error message
> doesn't seem useful.
>
Thanks for the comments, Euler and Julien.
From | Date | Subject | |
---|---|---|---|
Next Message | Anton A. Melnikov | 2022-08-21 14:33:57 | [BUG] Logical replica crash if there was an error in a function. |
Previous Message | Junwang Zhao | 2022-08-21 13:46:42 | Re: timing information for switching database |