Re: pg_resetwal: refuse to run when backup_label exists - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: pg_resetwal: refuse to run when backup_label exists
Date
Msg-id ar8mhs05SzC4hjmu@paquier.xyz
Whole thread
In response to pg_resetwal: refuse to run when backup_label exists  (shihao zhong <zhong950419@gmail.com>)
Responses Re: pg_resetwal: refuse to run when backup_label exists
List pgsql-hackers
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

Attachment

pgsql-hackers by date:

Previous
From: Zhijie Hou
Date:
Subject: Re: Fix apply worker crash when subscriber table has only a deferrable primary key
Next
From: Henson Choi
Date:
Subject: Re: [PATCH] Add pg_get_table_ddl() to reconstruct CREATE TABLE statements