Re: recovery_min_apply_delay in archive recovery causes assertionfailure in latch - Mailing list pgsql-hackers

From Fujii Masao
Subject Re: recovery_min_apply_delay in archive recovery causes assertionfailure in latch
Date
Msg-id CAHGQGwEG98pn1tt4Rqb=CcW+yPk5x_zjSZOYZEqSzx6SJkdZdg@mail.gmail.com
Whole thread Raw
In response to Re: recovery_min_apply_delay in archive recovery causes assertionfailure in latch  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
On Sat, Dec 14, 2019 at 12:35 AM Alvaro Herrera
<alvherre@2ndquadrant.com> wrote:
>
> On 2019-Oct-19, Michael Paquier wrote:
>
> > On Thu, Oct 17, 2019 at 02:35:13PM +0900, Michael Paquier wrote:
> > > ArchiveRecoveryRequested will be set to true if recovery.signal or
> > > standby.signal are found, so it seems to me that you can make all
> > > those checks more simple by removing from the equation
> > > StandbyModeRequested, no?  StandbyModeRequested is never set to true
> > > if ArchiveRecoveryRequested is not itself true.
> >
> > For the sake of the archives, this has been applied by Fujii-san as of
> > ec1259e8.
>
> So, the commit message says
>
>     Fix failure of archive recovery with recovery_min_apply_delay enabled.
>
>     recovery_min_apply_delay parameter is intended for use with streaming
>     replication deployments. However, the document clearly explains that
>     the parameter will be honored in all cases if it's specified. So it should
>     take effect even if in archive recovery. But, previously, archive recovery
>     with recovery_min_apply_delay enabled always failed, and caused assertion
>     failure if --enable-caasert is enabled.
>
> but I'm not clear how would this problem manifest in the case of a build
> with assertions disabled.  Will it keep sleeping beyond the specified
> time?

When assertion is disabled, the recovery exists with the following messages.

FATAL:  cannot wait on a latch owned by another process
LOG:  startup process (PID 81007) exited with exit code 1
LOG:  terminating any other active server processes
LOG:  database system is shut down

Regards,

-- 
Fujii Masao



pgsql-hackers by date:

Previous
From: Kyotaro Horiguchi
Date:
Subject: Re: non-exclusive backup cleanup is mildly broken
Next
From: Michael Paquier
Date:
Subject: Re: psql's \watch is broken