Re: beta testing version
От | Don Baccus |
---|---|
Тема | Re: beta testing version |
Дата | |
Msg-id | 3.0.1.32.20001203223247.01ae67c0@mail.pacifier.com обсуждение исходный текст |
Ответ на | Re: beta testing version (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
At 02:47 PM 12/1/00 -0500, Tom Lane wrote: >All we can do is the best we can ;-). In that light, I think it's >reasonable for Postgres to proceed on the assumption that fsync does >what it claims to do, ie, all blocks are written when it returns. >We can't realistically expect to persuade a disk controller that >reorders writes to stop doing so. We can, however, expect that we've >minimized the probability of failures induced by anything other than >disk hardware failure or power failure. Right. This is very much the guarantee that RAID (non-zero) makes, except "other than disk hardware failure" is replaced by "other than the failure of two drives". RAID gives you that (very, very substantial boost which is why it is so popular for DB servers). It doesn't give you power failure assurance for much the same reason that PG (or Oracle, etc) can. If transaction processing alone could give you protection against a single disk hardware failure, Oracle wouldn't've bothered implementing mirroring in the past before software (and even reasonable hardware) RAID was available. Likewise, if mirroring + transaction processing could protect against disks hosing themselves in power failure situations Oracle wouldn't suggest that enterprise level customers invest in external disk subsystems with battery backup sufficient to guarantee everything the db server believes has been written really is written. Of course, Oracle license fees are high enough that proper hardware support tends to look cheap in comparison... Vadim's WAL code is excellent, and the fact that we run in essence with -F performance and also less write activity to the disk both increases performance, and tends to lessen the probability that the disk will actually be writing a block when the power goes off. The dice aren't quite so loaded against the server with this lowered disk activity... - Don Baccus, Portland OR <dhogaza@pacifier.com> Nature photos, on-line guides, Pacific Northwest Rare Bird Alert Serviceand other goodies at http://donb.photo.net.
В списке pgsql-hackers по дате отправления: