| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "Gregory Maxwell" <gmaxwell(at)gmail(dot)com> |
| Cc: | "mark(at)mark(dot)mielke(dot)cc" <mark(at)mark(dot)mielke(dot)cc>, "Simon Riggs" <simon(at)2ndquadrant(dot)com>, "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 |
| Date: | 2006-10-24 18:07:29 |
| Message-ID: | 21857.1161713249@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
"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.
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.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Gurjeet Singh | 2006-10-24 18:10:09 | Re: New CRC algorithm: Slicing by 8 |
| Previous Message | Joshua D. Drake | 2006-10-24 18:07:28 | Re: Incorrect behavior with CE and ORDER BY |