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 CAGRkXqR1LskQx1qKNdOj3MTAD_zaSGtCBs0LEmHS15X_+O=ArA@mail.gmail.com
Whole thread
In response to Re: pg_resetwal: refuse to run when backup_label exists  (Michael Paquier <michael@paquier.xyz>)
Responses Re: pg_resetwal: refuse to run when backup_label exists
List pgsql-hackers
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.

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

Thanks,
Shihao

Attachment

pgsql-hackers by date:

Previous
From: Narayanan Venkateswaran
Date:
Subject: Re: Use instr_time for pg_stat_database block read/write time counters
Next
From: Narayanan Venkateswaran
Date:
Subject: Re: postgres_fdw: Fix costing of remote sorts without remote estimates