On Thu, Oct 27, 2011 at 13:19, Heikki Linnakangas
<heikki.linnakan...@enterprisedb.com> wrote:
> On 27.10.2011 14:09, Fujii Masao wrote:
>> On Thu, Oct 27, 2011 at 7:48 PM, Magnus Hagander<mag...@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

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/

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to