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@2ndQuadrant.com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us
"PostgreSQL 9.0 High Performance": http://www.2ndQuadrant.com/books
