On Thu, Oct 27, 2011 at 13:19, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.com> wrote:
> On 27.10.2011 14:09, Fujii Masao wrote:
>>
>> On Thu, Oct 27, 2011 at 7:48 PM, Magnus Hagander<magnus@hagander.net>
>> wrote:
>>>
>>> I'm rewriting the handling of partial files per the other thread
>>> started by Heikki. The idea is that there will be an actual .partial
>>> file in there when pg_receivexlog has ended, and you have to deal with
>>> it manually. The typical way would be to pad it with zeroes to the
>>> end. Doing such padding would solve this recovery issue, correct?
>>
>> Yes. But that sounds unuserfriendly. Padding the WAL file manually
>> is easy-to-do for a user?
>
> "truncate -s 16M <file>" works at least on my Linux system. Not sure how
> you'd do it on Windows.
Yeah, taht's easy enough. I don't think there are similar tools on
windows, but we could probably put together a quick script for people
to use if necessary.
> Perhaps we should add automatic padding in the server, though. It wouldn't
> take much code in the server, and would make life easier for people writing
> their scripts. Maybe even have the backend check for a .partial file if it
> can't find a regularly named XLOG file. Needs some thought..
I'd definitely want to avoid anything that requires pg_receivexlog to
actually *parse* the WAL. That'll make it way more complex than I'd
like.
Having recovery consider a .partial file might be interesting. It
could consider that only if there are no other complete files
available, or something like that?
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
