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 CAHGQGwF+u4fmkPr01FgbLL9Fr0b4pjgxK=y15D3wsfXNVRo4CQ@mail.gmail.com
Whole thread Raw
In response to Re: recovery_min_apply_delay in archive recovery causes assertionfailure in latch  (Fujii Masao <masao.fujii@gmail.com>)
Responses Re: recovery_min_apply_delay in archive recovery causes assertionfailure in latch
List pgsql-hackers
On Fri, Oct 4, 2019 at 9:03 PM Fujii Masao <masao.fujii@gmail.com> wrote:
>
> On Mon, Sep 30, 2019 at 12:49 AM Fujii Masao <masao.fujii@gmail.com> wrote:
> >
> > Hi,
> >
> > I got the following assertion failure when I enabled recovery_min_apply_delay
> > and started archive recovery (i.e., I put only recovery.signal not
> > standby.signal).
> >
> > TRAP: FailedAssertion("latch->owner_pid == MyProcPid", File:
> > "latch.c", Line: 522)
> >
> > Here is the example to reproduce the issue:
> >
> > ----------------------------
> > initdb -D data
> > pg_ctl -D data start
> > psql -c "alter system set recovery_min_apply_delay to '60s'"
> > psql -c "alter system set archive_mode to on"
> > psql -c "alter system set archive_command to 'cp %p ../arch/%f'"
> > psql -c "alter system set restore_command to 'cp ../arch/%f %p'"
> > mkdir arch
> > pg_basebackup -D bkp -c fast
> > pgbench -i
> > pgbench -t 1000
> > pg_ctl -D data -m i stop
> > rm -rf bkp/pg_wal
> > mv data/pg_wal bkp
> > rm -rf data
> > mv bkp data
> > touch data/recovery.signal
> > pg_ctl -D data -W start
> > ----------------------------
> >
> > The latch that causes this assertion failure is recoveryWakeupLatch.
> > The ownership of this latch is taken only when standby mode is
> > requested. But this latch can be used when starting archive recovery
> > with recovery_min_apply_delay set even though it's unowned.
> > So the assertion failure happened.
> >
> > Attached patch fixes this issue by making archive recovery always ignore
> > recovery_min_apply_delay. This change is OK because
> > recovery_min_apply_delay was introduced for standby mode, I think.
>
> No, I found the following description in the doc.
>
> ------------------------------
> This parameter is intended for use with streaming replication deployments;
> however, if the parameter is specified it will be honored in all cases
> ------------------------------
>
> So archive recovery with recovery_min_apply_delay enabled would be
> intended configuration. My patch that changes archive recovery so that
> it always ignores thesetting might be in wrong direction. Maybe we should
> make recovery_min_apply_delay work properly even in archive recovery.
> Thought?

Patch attached. This patch allows archive recovery with
recovery_min_apply_delay set, but not crash recovery.

Regards,

-- 
Fujii Masao

Attachment

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [PATCH] Add some useful asserts into View Options macroses
Next
From: Bruce Momjian
Date:
Subject: Re: format of pg_upgrade loadable_libraries warning