Alvaro Herrera wrote: > On Tue, Aug 16, 2005 at 09:12:31AM -0700, Josh Berkus wrote: > > >>However, you are absolutely correct in that it's *relative* advice, not >>absolute advice. If, for example, you're using a $100,000 EMC SAN as your >>storage you'll probably be better off giving it everything and letting its >>controller and cache handle disk allocation etc. On the other hand, if >>you're dealing with the 5 drives in a single Dell 6650, I've yet to encounter >>a case where a separate xlog disk did not benefit an OLTP application. > > > I've been asked this a couple of times and I don't know the answer: what > happens if you give XLog a single drive (unmirrored single spindle), and > that drive dies? So the question really is, should you be giving two > disks to XLog? >
I can propose a simple test. Create a test database. Run postgres, insert a bunch of stuff. Stop postgres. Delete everything in the pg_xlog directory. Start postgres again, what does it do? I suppose to simulate more of a failure mode, you could kill -9 the postmaster (and all children processes) perhaps during an insert, and then delete pg_xlog. But I would like to hear from the postgres folks what they *expect* would happen if you ever lost pg_xlog. What about something like keeping pg_xlog on a ramdisk, and then rsyncing it to a hard-disk every 5 minutes. If you die in the middle, does it just restore back to the 5-minutes ago point, or does it get more thoroughly messed up? For some people, a 5-minute old restore would be okay, as long as you still have transaction safety, so that you can figure out what needs to be restored. John =:->
signature.asc
Description: OpenPGP digital signature
