On Tue, 2006-10-24 at 14:07 -0400, Tom Lane wrote: > "Gregory Maxwell" <[EMAIL PROTECTED]> writes: > > I'm not aware of any other system which can guaranteed the atomicity > > of 8k writes. > > The reasoning for supporting full_page_writes = off is that if you have > a stable kernel and suitable backup power, battery backed write cache, > etc, your risk of a partially completed write() may be low enough to > be acceptable. Obviously there are no 100.00% guarantees, but that's > what you keep backups for ... > > Simon is essentially arguing that if we are willing to assume no > incomplete write() we may as well assume it for WAL too. This seems > to me to be raising the risk significantly, but I admit that I can't > put my finger on why exactly.
I agree about the significant additional risk, hence the additional parameter. I'll do some internal testing to see what the risk-reward is. If that seems worthwhile, then I'll post the patch for general testing/comment. (Incidentally, having GUCs that depend on other GUCs is bad news since they are set alphabetically. I'd want to only allow wal_checksum=off iff full_page_writes=off, which will work, but only because W comes after F and for no other reason. Generic solution for dependent GUCs would be great...) > One point not directly related to crash safety is whether CRC checking > isn't still going to be a good idea when PITR is enabled. Archived WAL > files are going to have been through a great deal more transferring than > ones merely being used to recover from a crash. Agreed. Both disks and tapes/other mechanisms must be known CRC-safe before this idea would be worth using in production. Many enterprises do already think they have bomb-proof kit, so we may as well support them in that belief. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org
