On Mon, Oct 30, 2017 at 9:43 AM, Chris Travers <chris.trav...@adjust.com> wrote: > Are there any cases right now where you have features added by extensions > that write to directories which are required for a rewind?
In some of the stuff I maintain, I actually have one case now of a configuration file included with include_if_exists by postgresql.conf and is expected to be generated by a component that my code doing the rewind has no direct access on... I can control how pg_rewind kicks in, but I think that you would actually break silently the current code, which is scary especially if I don't control the code where pg_rewind is called when Postgres 11 gets integrated into the product I am thinking about, and even more scary if there is no way to include something. > The problem with an exclude list is that we cannot safely exclude > configuration files or logs (because these could be named anything), right? You have the exact same problem with base backups now, and any configuration files created by extensions are a per-case problem... The pattern that base backups now use is an exclude list. In the future I would rather see base backups and pg_rewind using the same infrastructure for both things: - pg_rewind should use the replication protocol with BASE_BACKUP. Having it rely on root access now is crazy. - BASE_BACKUP should have an option where it is possible to exclude custom paths. What you are proposing here would make both diverge more, which is in my opinion not a good approach. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
