On Mon, Oct 29, 2018 at 12:09:21PM +0300, Alexey Kondratov wrote: > Currently in the patch, with dry-run option (-n) pg_rewind only fetches > missing WALs to be able to build file map, while doesn't touch any data > files. So I guess it behaves exactly as you described and we do not need a > separate tool.
Makes sense perhaps. Fetching only WAL segments which are needed for the file map is critical, as you don't want to spend bandwidth for nothing. Now, I look at your patch, and I can see things to complain about, at least three at short glance: - The TAP test added will fail on Windows. - Simply copy-pasting RestoreArchivedWAL() from the backend code to pg_rewind is not an acceptable option. You don't care about %r either in this case. - Reusing the GUC parser is something I would avoid as well. Not worth the complexity. Another thing I am wondering is: do we actually need something complex? What we want to know is what data is necessary to build the file map, so we could also add an option to pg_rewind which checks what segments are necessary and lets the user know about them? This also avoids the security-related problems of manipulating a command at option-level. This kind of options makes folks willing to use more sensitive data on command line, which is not always a good idea... -- Michael
signature.asc
Description: PGP signature
