|From:||"Simon Riggs" <simon(at)2ndquadrant(dot)com>|
|To:||"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|Cc:||"Gregory Maxwell" <gmaxwell(at)gmail(dot)com>, <mark(at)mark(dot)mielke(dot)cc>, "Gurjeet Singh" <singh(dot)gurjeet(at)gmail(dot)com>, "PGSQL Hackers" <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: New CRC algorithm: Slicing by 8|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
On Tue, 2006-10-24 at 14:07 -0400, Tom Lane wrote:
> "Gregory Maxwell" <gmaxwell(at)gmail(dot)com> 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
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
> 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.
|Next Message||Martijn van Oosterhout||2006-10-24 20:23:07||Re: [SPAM?] Re: Asynchronous I/O Support|
|Previous Message||Ron Mayer||2006-10-24 19:53:23||Re: [SPAM?] Re: Asynchronous I/O Support|