On Tue, Oct 25, 2011 at 13:54, Fujii Masao <masao.fu...@gmail.com> wrote: > On Tue, Oct 25, 2011 at 7:19 PM, Magnus Hagander <mag...@hagander.net> wrote: >> I don't think we should necessarily give up completely. But doing a >> pg_basebackup way *first* seems reasonable - because it's going to be >> the easiest one to "get right", given that we have more control there. >> Doesn't mean we shouldn't extend it in the future... > > Agreed. The question is -- how far should we change pg_basebackup to > "get right"? I think it's not difficult to change it so that it backs up > the control file at the end. But eliminating the need for full_page_writes=on > seems not easy. No? So I'm not inclined to do that in at least first commit. > Otherwise, I'm afraid the patch would become huge.
It's more server side of base backups than the actual pg_basebackup tool of course, but I'm sure that's what we're all referring to here. Personally, I'd see the fpw stuff as part of the infrastructure needed. Meaning that the fpw stuff should go in *first*, and the pg_basebackup stuff later. If we want something to go in early, that could be as simple as a version of pg_basebackup that runs against the slave but only if full_page_writes=on on the master. If it's not, it throws an error. Then we can improve upon that by adding handling of fpw=off, first by infrastructure, then by tool. Doing it piece by piece like that is probably a good idea, since as you say, all at once will be pretty huge. -- 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