On Thu, Mar 18, 2021 at 12:46 PM Fujii Masao <masao.fu...@oss.nttdata.com> wrote: > On 2021/03/17 11:58, Kyotaro Horiguchi wrote: > > The first suggested signature for pg_terminate_backend() with timeout > > was pg_terminate_backend(pid, timeout). The current signature (pid, > > wait?, timeout) looks redundant. Maybe the reason for rejecting 0 > > astimeout is pg_terminate_backend(pid, true, 0) looks odd but it we > > can wait forever in that case (as other features does). > > I'm afraid that "waiting forever" can cause something like deadlock situation, > as follows. We have no mechanism to detect this for now. > > 1. backend 1 took the lock on the relation A. > 2. backend 2 took the lock on the relation B. > 3. backend 1 tries to take the lock on the relation B and is waiting for > the lock to be released. > 4. backend 2 accidentally executes pg_wait_for_backend_termination() with > the pid of backend 1, and then is waiting for backend 1 to be terminated.
Yeah this can happen. So, as stated upthread, how about a timeout 0 (which is default) telling "don't wait", erroring out on negative value and when specified a positive milliseconds value, then wait for that amount of time. With this semantics, we can remove the wait flag for pg_terminate_backend(pid, 0). Thoughts? And for pg_wait_for_backend_termination timeout 0 or negative, we error out. Thoughts? With Regards, Bharath Rupireddy. EnterpriseDB: http://www.enterprisedb.com
