On 06/26/2015 10:10 PM, Andres Freund wrote:
On 2015-06-26 15:07:59 -0400, Robert Haas wrote:
I realize that the recent fsync fiasco demonstrated that people keep
files not readable by PG in the data directory
It wasn't unreadable files that were the primary problem, it was files
with read only permissions, no?
Right.
"oops, I can't read this, that's probably OK" just does not seem good
enough.
Agreed.
After thinking about this some more, I think it'd be acceptable if we
just fail, if there are any non-writeable files in the data directory.
The typical scenario is that postgresql.conf, or an SSL cert file, is a
symlink to outside the data directory. It seems reasonable to require
that the DBA just removes the symlink before running pg_rewind, and
restores it afterwards if appropriate. In many cases, you would *not*
want to overwrite your config files, SSL cert files, etc., so the DBA
will need to script backing up and restoring those anyway.
(It's a fair question whether pg_rewind should be copying those files in
the first place. I've opted for "yes", so that it's easy to explain the
behaviour of pg_rewind: the end result is the same as if you took a new
base backup from the source server. Whatever files you want to backup up
before you re-initialize from a base backup, you should also backup with
pg_rewind.)
But we'll still need to handle the pg_xlog symlink case somehow. Perhaps
it would be enough to special-case pg_xlog for now.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
