On 09/04/2015 08:14 AM, Michael Paquier wrote:
On Thu, Sep 3, 2015 at 9:53 PM, Stephen Frost <sfr...@snowman.net> wrote:
* Michael Paquier (michael.paqu...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
