Re: pg_resetwal: refuse to run when backup_label exists

From: shihao zhong <zhong950419(at)gmail(dot)com>
To: Joao Detomini <joao(dot)detomini(at)enterprisedb(dot)com>
Cc: David Steele <david(at)pgbackrest(dot)org>, Michael Paquier <michael(at)paquier(dot)xyz>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_resetwal: refuse to run when backup_label exists
Date: 2026-10-05 03:47:10
Message-ID: CAGRkXqQaD68S_8dDZPssGpD2aSqmKGP=0wZqkAUU=RvpgLiPvQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

Attachment Content-Type Size
v3-0002-Test-pg_resetwal-backup_label-check.patch application/octet-stream 2.0 KB
v3-0001-pg_resetwal-Refuse-to-run-when-backup_label-exist.patch application/octet-stream 3.2 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2026-10-05 03:51:44 Re: REPACK (CONCURRENTLY) might keep dropped-column data
Previous Message Hayato Kuroda (Fujitsu) 2026-10-05 03:35:35 RE: Session in aborted transaction misses effective_wal_level change