Re: Updated version of pg_receivexlog
Magnus Hagander <magnus@hagander.net>
From: Magnus Hagander <magnus@hagander.net>
To: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
Cc: Fujii Masao <masao.fujii@gmail.com>,
Jaime Casanova <jaime@2ndquadrant.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2011-10-27T11:23:24Z
Lists: pgsql-hackers
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/