Re: recovery_min_apply_delay in archive recovery causes assertion failure in latch

On Sat, Dec 14, 2019 at 12:35 AM Alvaro Herrera
<alvherre(at)2ndquadrant(dot)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