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 по дате отправления:

Предыдущее
От: Dean Rasheed
Дата:
Сообщение: RLS restrictive hook policies
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: Reduce ProcArrayLock contention