Heikki Linnakangas napsal(a):
> It would be
> simple to update the FSM at every heap insert and update record, but
> that then might be an unacceptable amount of overhead at recovery. Also,
> the index FSM is not yet updated during recovery.
I expect locking problems specially on small tables where FSM has only one level
instead slower recovery. Maybe background writer could update FSM info, but it
breaks modularity and It could bring problems during checkpoints.
<snip>
>
> There's one known bug left. If we crash after truncating a relation, and
> the truncation of the FSM doesn't hit the disk but the truncation of the
> main fork does, we can end up with an FSM that shows that there's free
> space on pages that don't exist anymore. The straightforward way to fix
> that is to put back the WAL-logging of FSM truncations, but given that I
> just ripped off all the rest of the WAL-logging, does anyone have other
> ideas?
What's about truncate FSM during WAL replay of main fork truncation record?
Zdenek
--
Zdenek Kotala Sun Microsystems
Prague, Czech Republic http://sun.com/postgresql
