On Sat, 4 Oct 2003, Bruce Momjian wrote:
> scott.marlowe wrote:
> > On Fri, 3 Oct 2003, scott.marlowe wrote:
> >
> > > On Fri, 3 Oct 2003, Tom Lane wrote:
> > > >
> > > > It'd be interesting to think about whether a write-caching IDE drive
> > > > could safely be used for data storage, if WAL is elsewhere.
> > >
> > > Well, I just so happen to have a machine with two drives in it. I'll get
> > > back to you on that.
> >
> > Ok, I just tested it. I put pg_xlog and pg_clog on a drive that was set
> > to write cache disabled, and left the data on a drive where caching was
> > enabled. The tps on a pgbench -c 5 -t 500 on the single drive was 45 to
> > 55. With the pg_[xc]log moved to another drive and all, I got up to 108
> > tps. About double performance, as you'd expect. I didn't test the data
> > drive with write caching disabled, but my guess is it wouldn't be any
> > slower since pgsql doesn't wait on the rest.
> >
> > I pulled the plug three times, and all three times the database came up in
> > recovery mode and sucessfully recovered. I didn't bother testing to see
> > if write caching would corrupt it as I'm pretty sure it would, it
> > certainly did when everything was on one drive.
>
> You would have had to pull the plug between the time the system did a
> checkpoint (and wrote to the write cache), and before it flushed the
> write cache to disk --- no idea how you would find that window, but my
> guess is that if you pulled the plug right after the checkpoint
> completed, the WAL recovery would fail.
I'm not sure what you mean. Are you talking about the failure more with
write cache enabled? That always failed when I tested it. I was testing
it with 80 parallel transactions, by the way. I'll try it anyway just to
be sure that it causes the problem I'm expecting it to (i.e. write cache
enabled on pg_xlog causes database corruption under heavy parallel load
when plug is pulled.)
