Re: pg_rewind failure by file deletion in source server - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: pg_rewind failure by file deletion in source server
Date
Msg-id 55BF60CA.5090005@iki.fi
Whole thread Raw
In response to Re: pg_rewind failure by file deletion in source server  (Michael Paquier <michael.paquier@gmail.com>)
List 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 by date:

Previous
From: Dean Rasheed
Date:
Subject: RLS restrictive hook policies
Next
From: Amit Kapila
Date:
Subject: Re: Reduce ProcArrayLock contention