On Mon, Oct 30, 2017 at 10:15 AM, Chris Travers
<chris.travers@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