Re: pg_resetwal: refuse to run when backup_label exists

On Mon, Sep 28, 2026 at 11:02:00PM -0700, shihao zhong wrote:
> Robert worried in [3] that people with a bad backup will just run
> pg_resetwal, which is worse than starting from the wrong checkpoint. This
> patch targets that step. A backup that still has its backup_label is the
> case where the user has everything needed for a correct restore, and
> pg_resetwal is the wrong tool. Now it says so before it does any damage. A
> user can still delete the file and rerun, but that is a second deliberate
> step, and the docs now say when that is safe.
>
> 0002 adds TAP tests and is optional. I think this is master only, since it
> changes what an existing command accepts.

FWIW, I don't think that we should restrict that at all. pg_resetwal
is a footgun if one does not know what he/she is doing. However, if
one knows his business, even using pg_resetwal on a data folder with a
backup_label file around can prove incredibly useful when salvaging
data from a corrupted instance.

One thing that may be interesting to me is something much different
than what you are sending: an option to overwrite DBState in
ControlFileData to something else than DB_SHUTDOWNED. Hence that
would be the opposite of a restriction.

Note: pg_resetwal should have been renamed a long time ago. Perhaps
it should just be pg_control_update or something like that. I am
pretty sure that pg_footgun has been mentioned to me once, at some
point. Jokes apart, *that* naming could be a serious option to make
people aware that this a tool you should not use if you do not
absolutely know what you are doing.
--
Michael