On 04/06/2011 06:33 PM, Ireneusz Pluta wrote:
I saw some recommendations from people on the net not to use background fsck when running PostgreSQL on FreeBSD. As I recall, these opinions were just thoughts of people which they shared with the community, following their bad experience caused by using background fsck.
Presumably you're talking about reports like these two: http://blog.e-shell.org/266 http://lists.freebsd.org/pipermail/freebsd-current/2007-July/074773.html
But waiting so much time (like now) during foreground fsck of a large data filesystem after unclean shutdown, makes me to come to this group to ask whether I really need to avoid background fsck on a PostgreSQL machine?
The soft update code used in FreeBSD makes sure that there's no damage to the filesystem that PostgreSQL can't recover from. Once the WAL is replayed after a crash, the database is consistent. The main purpose of the background fsck is to find "orphaned" space, things that the filesystem incorrectly remembers the state of in regards to whether it was allocated and used. In theory, there's no reason that can't happen in the background, concurrent with normal database activity.
In practice, background fsck is such an infrequently used piece of code that it's developed a bit of a reputation for being buggier than average. It's really hard to test it, filesystem code is complicated, and the sort of inconsistent data you get after a hard crash is often really surprising. I wouldn't be too concerned about the database integrity, but there is a small risk that background fsck will run into something unexpected and panic. And that's a problem you're much less likely to hit using the more stable regular fsck code; thus the recommendations by some to avoid it.
-- Greg Smith 2ndQuadrant US greg@xxxxxxxxxxxxxxx Baltimore, MD PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us "PostgreSQL 9.0 High Performance": http://www.2ndQuadrant.com/books -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
