| From: | Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com> |
|---|---|
| To: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, bharath(dot)rupireddyforpostgres(at)gmail(dot)com |
| Cc: | magnus(at)hagander(dot)net, houzj(dot)fnst(at)cn(dot)fujitsu(dot)com, pgsql-hackers(at)lists(dot)postgresql(dot)org, m(dot)usama(at)gmail(dot)com |
| Subject: | Re: A new function to wait for the backend exit after termination |
| Date: | 2021-03-18 07:16:54 |
| Message-ID: | 46b07837-cb7d-1fdd-860b-64893f782d3a@oss.nttdata.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
| From | Date | Subject | |
|---|---|---|---|
| Next Message | iwata.aya@fujitsu.com | 2021-03-18 07:18:42 | RE: libpq debug log |
| Previous Message | Julien Rouhaud | 2021-03-18 07:13:17 | Re: psql tab completion for \h with IMPORT FOREIGN SCHEMA |