RE: Enhance traceability of wal_level changes for backup management

On Tuesday, March 9, 2021 11:13 PM David Steele <david(at)pgmasters(dot)net>
> On 3/7/21 9:45 PM, osumi(dot)takamichi(at)fujitsu(dot)com wrote:
> > On Sun, Mar 7, 2021 3:48 AM Peter Eisentraut
> <peter(dot)eisentraut(at)enterprisedb(dot)com> wrote:
> >> On 28.01.21 01:44, osumi(dot)takamichi(at)fujitsu(dot)com wrote:
> >>>> (1) writing the time or LSN in the control file to indicate
> >>>> when/where wal_level is changed to 'minimal'
> >>>> from upper level to invalidate the old backups or make alerts to users.
> >>> I attached the first patch which implementes this idea.
> >>> It was aligned by pgindent and shows no regression.
> >>
> >> It's not clear to me what this is supposed to accomplish. I read the
> >> thread, but it's still not clear.
> >> What is one supposed to do with this information?
> > OK. The basic idea is to enable backup management tools to recognize
> > wal_level drop between *snapshots*.
> > When you have a snapshot of the cluster at one time and another one at
> > different time, with this new parameter, you can see if anything that
> > causes discontinuity from the drop happens in the middle of the two
> > snapshots without efforts to have a look at the WALs in between.
>
> As a backup software author, I don't see this feature as very useful.
>
> The problem is that there are lots of ways for WAL to go missing so
> monitoring the WAL archive for gaps is essential and this feature would not
> replace that requirement. The only extra information you'd get is the ability to
> classify the most recent gap as "intentional", maybe.
>
> So, -1 from me.
Thanks for giving me a meaningful viewpoint.
Let me sleep on it, about whether the new param doesn't help in all cases or not.

Best Regards,
Takamichi Osumi