I don't know a lot about base backup, but it sounds like full_page_writes must be turned on for base backup, in order to deal with the inconsistent reads of pages (which you might call torn pages) that can happen when you backup the data files while the database is running. The relevant parts of the WAL log are then copied separately (and consistently) once the backup of the data files is done, and used to "recover" the database into a consistent state later.
So, yes, good point -- double writes cannot replace the functionality of full_page_writes for base backup. If double writes were in use, they might be automatically switched over to full page writes for the duration of the base backup. And the double write file should not be part of the base backup. Dan ----- Original Message ----- From: "Fujii Masao" <masao.fu...@gmail.com> To: "Dan Scales" <sca...@vmware.com> Cc: "PG Hackers" <pgsql-hackers@postgresql.org> Sent: Monday, February 6, 2012 3:08:15 AM Subject: Re: [HACKERS] double writes using "double-write buffer" approach [WIP] On Sat, Jan 28, 2012 at 7:31 AM, Dan Scales <sca...@vmware.com> wrote: > Let me know if you have any thoughts/comments, etc. The patch is > enclosed, and the README.doublewrites is updated a fair bit. ISTM that the double-write can prevent torn-pages in neither double-write file nor data file in *base backup*. Because both double-write file and data file can be backed up while being written. Is this right? To avoid the torn-page problem, we should write FPI to WAL during online backup even if the double-write has been committed? Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
