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 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/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
