Thread: Re: [COMMITTERS] pgsql: Rethink the way FSM truncation works.

Re: [COMMITTERS] pgsql: Rethink the way FSM truncation works.

From
Alvaro Herrera
Date:
Heikki Linnakangas wrote:

> Rethink the way FSM truncation works. Instead of WAL-logging FSM
> 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.

I wonder if this would help cleanup smgrcreate by adding another
function on top of it in the new storage.c file, to handle the
TablespaceCreateDbspace call.

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support