Re: including pid's for `There are XX other sessions using the database`

Поиск
Список
Период
Сортировка
От Zhihong Yu
Тема Re: including pid's for `There are XX other sessions using the database`
Дата
Msg-id CALNJ-vT5RcaEF5JJn3a7pDnuEjcUvb+D+2Y+Q98K1kLePY4LpA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: including pid's for `There are XX other sessions using the database`  (Julien Rouhaud <rjuju123@gmail.com>)
Список pgsql-hackers


On Sun, Aug 21, 2022 at 6:39 AM Julien Rouhaud <rjuju123@gmail.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@eulerto.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. 

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Junwang Zhao
Дата:
Сообщение: Re: timing information for switching database
Следующее
От: "Anton A. Melnikov"
Дата:
Сообщение: [BUG] Logical replica crash if there was an error in a function.