RE: Enhance traceability of wal_level changes for backup management

Hello, Sawada-san

I'll continue the discussion of [2].
We talked about how to recognize the time or LSN
when/where wal_level is changed to 'none' there.

You said
> The use case I imagined is that the user temporarily
> changes wal_level to 'none' from 'replica' or 'logical' to speed up loading and
> changes back to the normal. In this case, the backups taken before the
> wal_level change cannot be used to restore the database to the point after the
> wal_level change. So I think backup management tools would want to
> recognize the time or LSN when/where wal_level is changed to ‘none’ in order
> to do some actions such as invalidating older backups, re-calculating backup
> redundancy etc.
> Actually the same is true when the user changes to ‘minimal’. The tools would
> need to recognize the time or LSN in this case too. Since temporarily changing
> wal_level has been an uncommon use case some tools perhaps are not aware
> of that yet. But since introducing wal_level = ’none’ could make the change
> common, I think we need to provide a way for the tools.

I wondered, couldn't backup management tools utilize the information
in the backup that is needed to be made when wal_level is changed to "none" for example ?

As I said before, existing backup management tools support
only wal_level=replica or logical at present. And, if they would wish to alter the
status quo and want to cover the changes over wal_levels, I felt it's natural that
they support feature like taking a full backup, trigged by the wal_level changes (or server stop).

This is because taking a backup is a must for wal_level=none,
as I described in the patch of wal_level=none.
For example, they could prepare an easy way to
take an offline physical backup when the server stops for changing the wal_level.
(Here, they can support the change to minimal, too.)

What did you think ?

[2] - https://www.postgresql.org/message-id/CAD21AoCotoAxxCmMVz6niwg4j6c3Er_-GboTLmHBft8pALpOGA%40mail.gmail.com

Best Regards,
Takamichi Osumi