Update FSM on WAL replay. This is a bit limited; the FSM is only updated
commit97cd1e801f283d951a35a739781ee6242ab40482
authorheikki <heikki>
Fri, 31 Oct 2008 19:40:27 +0000 (31 19:40 +0000)
committerheikki <heikki>
Fri, 31 Oct 2008 19:40:27 +0000 (31 19:40 +0000)
tree819dffa6559540a0a3fc909e7a8bc9bae83dff3e
parent3ff1e85d9cac923ec10ea6ef599d68b737a9f3b0
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