On 09/04/2015 08:14 AM, Michael Paquier wrote:
> On Thu, Sep 3, 2015 at 9:53 PM, Stephen Frost <sfrost@snowman.net> wrote:
>> * Michael Paquier (michael.paquier@gmail.com) wrote:
>>> On Thu, Sep 3, 2015 at 11:20 AM, Stephen Frost wrote:
>>>>> Not only, +clog, configuration files, etc.
>>>>
>>>> Configuration files? Perhaps you could elaborate?
>>>
>>> Sure. Sorry for being unclear. It copies everything that is not a
>>> relation file, a kind of base backup without the relation files then.
>>
>> How does that work on systems where the configuration files aren't
>> stored under PGDATA (Debian and derivatives, at least)?
>
> When a file is out of PGDATA, it is not fetched. Symlinks in PGDATA
> have their contents fetched as well if I recall correctly.
>
>> I guess I don't
>> quite see why it's necessary for pg_rewind to copy the configuration
>> files in the first place, it doesn't have the same role as
>> pg_basebackup, at least as I understand it.
>
> Of course, that's not mandatory to fetch them. It is as well not worth
> the complication to apply a filter to not fetch a portion of the
> files, and I think that's why Heikki took the approach to fetch
> everything in PGDATA (except relation files) because that was just
> more simple to implement as such for little gain.
It's also simpler to explain and reason about. The current behaviour of
pg_rewind is that the end-result is basically the same as completely
copying over the data directory. If we start to add smarts on what to
copy and what not, it gets a lot more complicated. Which configuration
files to copy, and which not? (Think postgresql.auto.conf...)
If you want to preserve a file, you can copy it elsewhere first, and
copy it back after running pg_rewind. Just as you would with "cp" or
"rsync" (well, with rsync I guess you could pass a command-line switch
to ignore some files). That might not be perfect, but it's a problem
you'll have to deal with if you're not using pg_rewind anyway.
- Heikki
