From: | Amul Sul <sulamul(at)gmail(dot)com> |
---|---|
To: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: using an end-of-recovery record in all cases |
Date: | 2021-09-03 10:26:35 |
Message-ID: | CAAJ_b96jh3hJFnFpx7aamZGb63v+NPXPUGdU8dSY0c3OvMT2nA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Sep 3, 2021 at 10:23 AM Kyotaro Horiguchi
<horikyota(dot)ntt(at)gmail(dot)com> wrote:
>
> At Thu, 2 Sep 2021 11:30:59 -0400, Robert Haas <robertmhaas(at)gmail(dot)com> wrote in
> > On Mon, Aug 9, 2021 at 3:00 PM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> > > I decided to try writing a patch to use an end-of-recovery record
> > > rather than a checkpoint record in all cases.
> > >
> > > The first problem I hit was that GetRunningTransactionData() does
> > > Assert(TransactionIdIsNormal(CurrentRunningXacts->latestCompletedXid)).
> > >
> > > Unfortunately we can't just relax the assertion, because the
> > > XLOG_RUNNING_XACTS record will eventually be handed to
> > > ProcArrayApplyRecoveryInfo() for processing ... and that function
> > > contains a matching assertion which would in turn fail. It in turn
> > > passes the value to MaintainLatestCompletedXidRecovery() which
> > > contains yet another matching assertion, so the restriction to normal
> > > XIDs here looks pretty deliberate. There are no comments, though, so
> > > the reader is left to guess why. I see one problem:
> > > MaintainLatestCompletedXidRecovery uses FullXidRelativeTo, which
> > > expects a normal XID. Perhaps it's best to just dodge the entire issue
> > > by skipping LogStandbySnapshot() if latestCompletedXid happens to be
> > > 2, but that feels like a hack, because AFAICS the real problem is that
> > > StartupXLog() doesn't agree with the rest of the code on whether 2 is
> > > a legal case, and maybe we ought to be storing a value that doesn't
> > > need to be computed via TransactionIdRetreat().
> >
> > Anyone have any thoughts about this?
>
> I tried to reproduce this but just replacing the end-of-recovery
> checkpoint request with issuing an end-of-recovery record didn't cause
> make check-workd fail for me. Do you have an idea of any other
> requirement to cause that?
>
You might need the following change at the end of StartupXLOG():
- if (promoted)
- RequestCheckpoint(CHECKPOINT_FORCE);
+ RequestCheckpoint(CHECKPOINT_FORCE);
Regards,
Amul
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2021-09-03 10:36:20 | Re: Added schema level support for publication. |
Previous Message | Dilip Kumar | 2021-09-03 10:23:17 | Re: [Proposal] Fully WAL logged CREATE DATABASE - No Checkpoints |