On Sat, Dec 14, 2019 at 12:35 AM Alvaro Herrera <alvhe...@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
