| 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 |
| 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 |