On 08/03/2015 07:01 AM, Michael Paquier wrote:
On Sun, Aug 2, 2015 at 4:01 AM, Heikki Linnakangas wrote:
Perhaps it's best if we copy all the WAL files from source in copy-mode, but
not in libpq mode. Regarding old WAL files in the target, it's probably best
to always leave them alone. They should do no harm, and as a general
principle it's best to avoid destroying evidence.
It'd be nice to get some fix for this for alpha2, so I'll commit a fix to do
that on Monday, unless we come to a different conclusion before that.
+1. Both things sound like a good plan to me.
I had some trouble implementing that. Recovery seemed to get confused
sometimes, when it didn't find some of the WAL files in pg_xlog
directory, even though it could fetch them through streaming
replication. I'll have to investigate that further, but in the meantime,
to have some fix in place for alpha2, I committed an even simpler fix
for the immediate issue that pg_xlog is a symlink: just pretend that
"pg_xlog" is a normal directory, even when it's a symlink.
I'll continue to investigate what was wrong with my initial attempt. And
it would be nice to avoid copying the pre-allocated WAL files from the
source, because it's really unnecessary. But this fixes the immediate
problem that pg_rewind didn't work at all if pg_xlog was a symlink.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
