Re: [COMMITTERS] pgsql: Rethink the way FSM truncation works. - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: [COMMITTERS] pgsql: Rethink the way FSM truncation works.
Date
Msg-id 20081119133629.GF3764@alvh.no-ip.org
Whole thread Raw
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: "Rushabh Lathia"
Date:
Subject: Re: Problem with Bitmap Heap Scan
Next
From: Gregory Stark
Date:
Subject: New bug