Re: pg_rewind failure by file deletion in source server
От | Heikki Linnakangas |
---|---|
Тема | Re: pg_rewind failure by file deletion in source server |
Дата | |
Msg-id | 55BF60CA.5090005@iki.fi обсуждение исходный текст |
Ответ на | Re: pg_rewind failure by file deletion in source server (Michael Paquier <michael.paquier@gmail.com>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: