Chris Travers wrote: > On Mon, Sep 4, 2017 at 12:23 PM, Michael Paquier <michael.paquier@gmail.com> > wrote: > > > On Mon, Sep 4, 2017 at 7:21 PM, Michael Paquier > > <michael.paquier@gmail.com> wrote: > > > A simple idea would be to pass as a parameter a regex on which we > > > check files to skip when scanning the directory of the target remotely > > > or locally. This needs to be used with care though, it would be easy > > > to corrupt an instance. > > > > I actually shortcut that with a strategy similar to base backups: logs > > are on another partition, log_directory uses an absolute path, and > > PGDATA has no reference to the log path. > > Yeah, it is quite possible to move all these out of the data directory, but > bad things can happen when you accidentally copy configuration or logs over > those on the target and expecting that all environments will be properly > set up to avoid these problems is not always a sane assumption.
I agree that operationally it's better if these files weren't in PGDATA to start with, but from a customer support perspective, things are frequently not already setup like that, so failing to support that scenario is a loser.
I wonder how portable fnmatch() is in practice (which we don't currently use anywhere). A shell glob seems a more natural interface to me for this than a regular expression.
I think the simplest solution for now is to skip any files ending in .conf, .log, and serverlog.
Long run, it would be nice to change pg_rewind from an opt-out approach to an approach of processing the subdirectories we know are important.
It is worth noting further that if you rewind in the wrong way, in a cascading replication environment, you can accidentally change your replication topology if you clobber the recovery.conf from another replica and there is no way to ensure that this file is not in the data directory since it MUST be put there.
