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

From shihao zhong
Subject Re: pg_resetwal: refuse to run when backup_label exists
Date
Msg-id CAGRkXqQaD68S_8dDZPssGpD2aSqmKGP=0wZqkAUU=RvpgLiPvQ@mail.gmail.com
Whole thread
In response to Re: pg_resetwal: refuse to run when backup_label exists  (Joao Detomini <joao.detomini@enterprisedb.com>)
Responses Re: pg_resetwal: refuse to run when backup_label exists
List 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

pgsql-hackers by date:

Previous
From: "Hayato Kuroda (Fujitsu)"
Date:
Subject: RE: Session in aborted transaction misses effective_wal_level change
Next
From: Fujii Masao
Date:
Subject: Re: REPACK (CONCURRENTLY) might keep dropped-column data