Re: Transactions involving multiple postgres foreign servers, take 2
От | Kyotaro Horiguchi |
---|---|
Тема | Re: Transactions involving multiple postgres foreign servers, take 2 |
Дата | |
Msg-id | 20201020.120723.471434639707721851.horikyota.ntt@gmail.com обсуждение исходный текст |
Ответ на | RE: Transactions involving multiple postgres foreign servers, take 2 ("tsunakawa.takay@fujitsu.com" <tsunakawa.takay@fujitsu.com>) |
Ответы |
RE: Transactions involving multiple postgres foreign servers, take 2
|
Список | pgsql-hackers |
At Tue, 20 Oct 2020 02:44:09 +0000, "tsunakawa.takay@fujitsu.com" <tsunakawa.takay@fujitsu.com> wrote in > From: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> > > Using pg_cancel_backend() and pg_terminate_backend() a DBA can cancel > > running query from any backend or terminate a backend. For either to > > work the backend needs to be interruptible. IIRC, Robert had made an > > effort to make postgres_fdw interruptible few years back. > > Yeah, I know those functions. Sawada-san was talking about Ctrl + C, so I responded accordingly. > > Also, how can the DBA find sessions to run those functions against? Can he tell if a session is connected to or runningSQL to a given foreign server? Can he terminate or cancel all session with one SQL command that are stuck in accessinga particular foreign server? I don't think the inability to cancel all session at once cannot be a reason not to not to allow operators to cancel a stuck session. > Furthermore, FDW is not cancellable in general. So, I don't see a point in trying hard to make only commit be cancelable. I think that it is quite important that operators can cancel any process that has been stuck for a long time. Furthermore, postgres_fdw is more likely to be stuck since network is involved so the usefulness of that feature would be higher. regards. -- Kyotaro Horiguchi NTT Open Source Software Center
В списке pgsql-hackers по дате отправления: