Re: Updated version of pg_receivexlog
От | Magnus Hagander |
---|---|
Тема | Re: Updated version of pg_receivexlog |
Дата | |
Msg-id | CABUevEwv8gEp2EddQJs=n5W0ot0UxmYG5nni2XkQ6KCd6i9beA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Updated version of pg_receivexlog (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>) |
Ответы |
Re: Updated version of pg_receivexlog
Re: Updated version of pg_receivexlog |
Список | 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/
В списке pgsql-hackers по дате отправления: