Re: Deadlock between backend and recovery may not be detected - Mailing list pgsql-hackers

From Kyotaro Horiguchi
Subject Re: Deadlock between backend and recovery may not be detected
Date
Msg-id 20210106.095728.2012169039047848346.horikyota.ntt@gmail.com
Whole thread Raw
In response to Re: Deadlock between backend and recovery may not be detected  (Fujii Masao <masao.fujii@oss.nttdata.com>)
List pgsql-hackers
At Tue, 5 Jan 2021 15:26:50 +0900, Fujii Masao <masao.fujii@oss.nttdata.com> wrote in 
> 
> 
> On 2020/12/25 13:16, Kyotaro Horiguchi wrote:
> > At Wed, 23 Dec 2020 21:42:47 +0900, Fujii Masao
> > <masao.fujii@oss.nttdata.com> wrote in
> >> you. Attached
> >> is the updated of the patch. What about this version?
> > The patch contains a hunk in the following structure.
> > +    if (got_standby_lock_timeout)
> > +        goto cleanup;
> > +
> > +    if (got_standby_deadlock_timeout)
> > +    {
> > ...
> > +    }
> > +
> > +cleanup:
> > It is eqivalent to
> > +    if (!got_standby_lock_timeout && got_standby_deadlock_timeout)
> > +    {
> > ...
> > +    }
> > Is there any reason for the goto?
> 
> Yes. That's because we have the following code using goto.
> 
> +               /* Quick exit if there's no work to be done */
> +               if (!VirtualTransactionIdIsValid(*backends))
> +                       goto cleanup;

It doesn't seem to be the *cause*.  Such straight-forward logic with
three-depth indentation is not a thing that should be avoided using
goto even if PROCSIG_RECOVERY_CONFLICT_STARTUP_DEADLOCK is too lengty
and sticks out of 80 coloumns.

> Regarding the back-patch, I was thinking to back-patch this to all the
> supported branches. But I found that it's not easy to do that to v9.5
> because v9.5 doesn't have some infrastructure code that this bug fix
> patch depends on. So at least the commit 37c54863cf as the
> infrastructure
> also needs to be back-patched to v9.5. And ISTM that some related
> commits
> f868a8143a and 8f0de712c3 need to be back-patched. Probably there
> might
> be some other changes to be back-patched. Unfortunately they cannot be
> applied to v9.5 cleanly and additional changes are necessary.
> 
> This situation makes me feel that I'm inclined to skip the back-patch
> to v9.5.
> Because the next minor version release is the final one for v9.5. So
> if we
> unexpectedly introduce the bug to v9.5 by the back-patch, there is no
> chance to fix that. OTOH, of course, if we don't do the back-patch,
> there is
> no chance to fix the deadlock detection bug since the final minor
> version
> for v9.5 doesn't include that bug fix. But I'm afraid that the
> back-patch
> to v9.5 may give more risk than gain.
> 
> Thought?

It seems to me that the final minor release should get fixes only for
issues that we have actually gotten complaints on, or critical-ish
known issues such as ones lead to server crash in normal paths. This
particular issue is neither of them.

So +1 for not back-patching to 9.5.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center



pgsql-hackers by date:

Previous
From: Justin Pryzby
Date:
Subject: Re: allow to \dtS+ pg_toast.*
Next
From: Bruce Momjian
Date:
Subject: Re: Context diffs