Re: pg_resetwal: refuse to run when backup_label exists

Hi Shihao,

Thanks for v3. I applied it on current master and the pg_resetwal
tests pass.

On -f: pg_resetwal only lets it override uncertainty about the state
of pg_control, not known facts about the directory. postmaster.pid is
the closest case. -f doesn't bypass it and the user has to delete the
file by hand, even though a stale one after a crash is normal. A
backup_label looks like that second kind to me, so I'd keep v3 as is.

Thanks,
João Marcelo

Em seg., 5 de out. de 2026 às 00:47, shihao zhong <zhong950419(at)gmail(dot)com>
escreveu:

> Hi Joao,
>
> T hanks for testing it, and for checking the order of operations.
>
> > The Discussion: trailer points at David's message
> > in the CF 4997 thread; I guess it should point at this thread.
>
> The patch came out of that thread. That message is where David said
> -f should not override the check. v3 keeps it and adds this thread as
> a second Discussion line.
>
> > And a
> > restored backup normally has tablespace_map too, while the check only
> > looks at backup_label; is ignoring it on purpose?
> Yes. The server reads tablespace_map only when backup_label is there.
> Without backup_label it renames the file to tablespace_map.old and
> starts as usual. So tablespace_map alone does not stop the server from
> starting, and there is nothing for pg_resetwal to guard against.
> v3 also leaves out the --cluster-state patches, as David suggested.
> 0001 and 0002 have no code changes.
>
> Thanks,
> Shihao
>
>