Re: pg_resetwal: refuse to run when backup_label exists

On 10/2/26 07:43, shihao zhong wrote:
> Hi Michael,
> > 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.
>
> That still works with the patch. The only change is that backup_label
> has to be removed before pg_resetwal and not after. Today it has to go
> anyway. After pg_resetwal -f the server stops with "could not locate
> required checkpoint record" until the file is removed. Both orders give
> the same data directory on master, pg_control and the new WAL segment
> included.
>
> Does that change your view? If not, I can let -f override the check.
> Then the patch is only a clearer error without -f, plus the doc
> paragraph.

Given that the server will not start after pg_resetwal until
backup_label is removed I think it makes sense to force the user to
remove it beforehand. I'd prefer they remove it manually but I suppose
we could have -f remove it. Either way, it seems like pg_resetwal should
leave the cluster in a state where it can be started.

> > 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.
>
> 0003 in the attached v2 is a first try for that. It adds
> --cluster-state, which takes shut-down, shut-down-in-recovery,
> shutting-down, in-crash-recovery, in-archive-recovery or in-production.
> DB_STARTUP is left out because the server refuses to start with it.
>
> With any value other than shut-down, the next start goes through crash
> recovery. One visible effect is that unlogged tables are emptied. Today
> they keep what was on disk after a crash and pg_resetwal -f.
I'd say this should be the subject of a separate patch and thread. I'm
honestly not sure how useful it would be aside from test scenarios.

Regards,
-David