Re: limiting performance impact of wal archiving.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Scott Carey wrote:
Using ext2 means that you're still exposed to fsck errors on boot after
a crash, which doesn't lose anything but you have to go out of your way
to verify you're not going to get stuck with your server down in that
case.
fsck on a filesystem with 1 folder and <checkpoint_segments> files is very
very fast.  Even if using WAL archiving, there won't be many
files/directories to check.  Fsck is not an issue if the partition is
exclusively for WAL.  You can even mount it direct, and avoid having the OS
cache those pages if you are using a caching raid controller
Right; that sort of thing--switching to a more direct mount, making sure fsck is setup to run automatically rather than dropping to a menu--is what I was alluding to when I said you had to go out of your way to make that work. It's not complicated, really, but by the time you've set everything up and done the proper testing to confirm it all worked as expected you've just spent a modest chunk of time. All I was trying to suggest is that there is a cost and some complexity, and that I feel there's no reason to justify that unless you're not bottlenecked specifically at WAL write volume.

--
Greg Smith    2ndQuadrant   Baltimore, MD
PostgreSQL Training, Services and Support
greg@xxxxxxxxxxxxxxx  www.2ndQuadrant.com


--
Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance

[Postgresql General]     [Postgresql PHP]     [PHP Users]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Yosemite]

  Powered by Linux