From: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
---|---|
To: | masao(dot)fujii(at)oss(dot)nttdata(dot)com |
Cc: | bharath(dot)rupireddyforpostgres(at)gmail(dot)com, nathandbossart(at)gmail(dot)com, sfrost(at)snowman(dot)net, bossartn(at)amazon(dot)com, rjuju123(at)gmail(dot)com, michael(at)paquier(dot)xyz, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Add checkpoint and redo LSN to LogCheckpointEnd log message |
Date: | 2022-02-25 06:31:12 |
Message-ID: | 20220225.153112.120893179127555595.horikyota.ntt@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
At Tue, 22 Feb 2022 17:44:01 +0900 (JST), Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> wrote in
> At Tue, 22 Feb 2022 01:59:45 +0900, Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com> wrote in
> >
> > > Of the following, I think we should do (a) and (b) to make future
> > > backpatchings easier.
> > > a) Use RedoRecPtr and PriorRedoPtr after they are assigned.
> > > b) Move assignment to PriorRedoPtr into the ControlFileLock section.
> >
> > I failed to understand how (a) and (b) can make the backpatching
> > easier. How easy to backpatch seems the same whether we apply (a) and
> > (b) or not...
>
> That premises that the patch applied to master contains (a) and (b).
> So if it doesn't, those are not need by older branches.
I was once going to remove them. But according the discussion below,
the patch for back-patching is now quite close to that for the master
branch. So I left them alone.
> > > d) Skip call to UpdateCheckPointDistanceEstimate() when RedoRecPtr <=
> > > PriorRedoPtr.
> >
> > But "RedoRecPtr <= PriorRedoPtr" will never happen, will it? Because a
>
> I didn't believe that it happens. (So, it came from my
> convervativeness, or laziness, or both:p) The code dates from 2009 and
> StartupXLOG makes a concurrent checkpoint with bgwriter. But as of at
> least 9.5, StartupXLOG doesn't directly call CreateCheckPoint. So I
> think that won't happen.
>
> So, in short, I agree to remove it or turn it into Assert().
It was a bit out of point. If we assume RedoRecPtr is always larger
than PriorRedoPtr and then we don't need to check that there, we
should also remove the "if (PriorRedoPtr < RedoRecPtr)" branch just
above, which means the patch for back-branches gets very close to that
for the master. Do we make such a large change on back branches?
Anyways this version once takes that way.
> > if (flags & CHECKPOINT_IS_SHUTDOWN)
> > ControlFile->state = DB_SHUTDOWNED_IN_RECOVERY;
> >
> > Same as above. IMO it's safer and better to always update the state
> > (whether the state is DB_IN_ARCHIVE_RECOVERY or not) if
> > CHECKPOINT_IS_SHUTDOWN flag is passed.
>
> That means we may exit recovery mode after ShutdownXLOG called
> CreateRestartPoint. I don't think that may happen. So I'd rather add
> Assert ((flags&CHECKPOINT_IS_SHUTDOWN) == 0) there instaed.
So this version for v14 gets updated in the following points.
Completely removed the code path for the case some other process runs
simultaneous checkpoint.
Removed the condition (RedoRecPtr > PriorRedoPtr) for
UpdateCheckPointDistanceEstimate() call.
Added an assertion to the recoery-end path.
# Honestly I feel this is a bit too much for back-patching, though.
While making patches for v12, I see a test failure of pg_rewind for
uncertain reason. I'm investigating that but I post this for
discussion.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
From | Date | Subject | |
---|---|---|---|
Next Message | Japin Li | 2022-02-25 06:32:22 | Re: [PATCH] add relation and block-level filtering to pg_waldump |
Previous Message | Wenjing Zeng | 2022-02-25 06:26:47 | Re: [Proposal] Global temporary tables |