Skip to content
Snippets Groups Projects
  • Heikki Linnakangas's avatar
    33960006
    Rethink the way FSM truncation works. Instead of WAL-logging FSM · 33960006
    Heikki Linnakangas authored
    truncations in FSM code, call FreeSpaceMapTruncateRel from smgr_redo. To
    make that cleaner from modularity point of view, move the WAL-logging one
    level up to RelationTruncate, and move RelationTruncate and all the
    related WAL-logging to new src/backend/catalog/storage.c file. Introduce
    new RelationCreateStorage and RelationDropStorage functions that are used
    instead of calling smgrcreate/smgrscheduleunlink directly. Move the
    pending rel deletion stuff from smgrcreate/smgrscheduleunlink to the new
    functions. This leaves smgr.c as a thin wrapper around md.c; all the
    transactional stuff is now in storage.c.
    
    This will make it easier to add new forks with similar truncation logic,
    like the visibility map.
    33960006
    History
    Rethink the way FSM truncation works. Instead of WAL-logging FSM
    Heikki Linnakangas authored
    truncations in FSM code, call FreeSpaceMapTruncateRel from smgr_redo. To
    make that cleaner from modularity point of view, move the WAL-logging one
    level up to RelationTruncate, and move RelationTruncate and all the
    related WAL-logging to new src/backend/catalog/storage.c file. Introduce
    new RelationCreateStorage and RelationDropStorage functions that are used
    instead of calling smgrcreate/smgrscheduleunlink directly. Move the
    pending rel deletion stuff from smgrcreate/smgrscheduleunlink to the new
    functions. This leaves smgr.c as a thin wrapper around md.c; all the
    transactional stuff is now in storage.c.
    
    This will make it easier to add new forks with similar truncation logic,
    like the visibility map.