After reading this discussion, I agree that pg_rewind needs to become smarter in order to be fully useful in production environments; right now there are many warts and corner cases that did not seem to have been considered during the initial development (which I think is all right, taking into account that its mere concept was complicated enough; so we need not put any blame on the original developers, rather the contrary).
I think we need to make the program simple to use (i.e. not have the user write shell globs for the common log file naming patterns) while remaining powerful (i.e. not forcibly copy any files that do not match hardcoded globs). Is the current dry-run mode enough to give the user peace of mind regarding what would be done in terms of testing globs etc? If not, maybe the debug mode needs to be improved (for instance, have it report the file size for each file that would be copied; otherwise you may not notice it's going to copy the 20GB log file until it's too late ...) Now, in order for any of this to happen, there will need to be a champion to define what the missing pieces are, write all those patches and see them through the usual (cumbersome, slow) procedure. Are you, Chris, willing to take the lead on that? -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers