Update FSM on WAL replay. This is a bit limited; the FSM is only updated
authorHeikki Linnakangas <heikki@enterprisedb.com>
Fri, 31 Oct 2008 19:40:27 +0000 (19:40 +0000)
committerHeikki Linnakangas <heikki@enterprisedb.com>
Fri, 31 Oct 2008 19:40:27 +0000 (19:40 +0000)
commitb008475a5748b68d58fea44ebfac8880d1901f09
treee84cde90d73fd8d88fdeb4b7f5e1ea46759e4260
parentd9a319525591bc437e4770b4e796a7517844a784
Update FSM on WAL replay. This is a bit limited; the FSM is only updated
on non-full-page-image WAL records, and quite arbitrarily, only if there's
less than 20% free space on the page after the insert/update (not on HOT
updates, though). The 20% cutoff should avoid most of the overhead, when
replaying a bulk insertion, for example, while ensuring that pages that
are full are marked as full in the FSM.

This is mostly to avoid the nasty worst case scenario, where you replay
from a PITR archive, and the FSM information in the base backup is really
out of date. If there was a lot of pages that the outdated FSM claims to
have free space, but don't actually have any, the first unlucky inserter
after the recovery would traverse through all those pages, just to find
out that they're full. We didn't have this problem with the old FSM
implementation, because we simply threw the FSM information away on a
non-clean shutdown.
src/backend/access/heap/heapam.c
src/backend/storage/freespace/freespace.c
src/include/storage/freespace.h