On Mon, Oct 30, 2017 at 10:15 AM, Chris Travers <chris.trav...@adjust.com> wrote: > This also brings up a fairly major concern more generally about control by > the way. A lot of cases where pg_rewind is called, the user doesn't > necessarily have much control on how it is called. Moreover in many of > these cases, the user is probably not in a position to understand the > internals well enough to grasp what to check after.
Likely they are not. > Right, but there is a use case difference between "I am taking a backup of a > server" and "I need to get the server into rejoin the replication as a > standby." The intersection of the first and second categories is not empty. Some take backups and use them to deploy standbys. > A really good example of where this is a big problem is with replication > slots. On a backup I would expect you want replication slots to be copied > in. I would actually expect the contrary, and please note that replication slots are not taken in a base backup, which is what the documentation says as well: https://www.postgresql.org/docs/10/static/protocol-replication.html "pg_dynshmem, pg_notify, pg_replslot, pg_serial, pg_snapshots, pg_stat_tmp, and pg_subtrans are copied as empty directories (even if they are symbolic links)." Some code I have with 9.6's pg_bsaebackup removes manually replication slots as this logic is new in 10 ;) >> 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. > > How does rep mgr or other programs using pg_rewind know what to exclude? Good question. Answers could come from folks such as David Steele (pgBackRest) or Marco (barman) whom I am attaching in CC. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers