From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
---|---|
To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [COMMITTERS] pgsql: Rethink the way FSM truncation works. |
Date: | 2008-11-19 13:36:29 |
Message-ID: | 20081119133629.GF3764@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers 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
From | Date | Subject | |
---|---|---|---|
Next Message | User Achernow | 2008-11-19 15:35:49 | libpqtypes - libpqtypes: created pqt_buf_xxx functions to abstract |
Previous Message | User Mkz | 2008-11-19 12:50:05 | pgbouncer - pgbouncer: Dynamic database creation for non-defined |
From | Date | Subject | |
---|---|---|---|
Next Message | Gregory Stark | 2008-11-19 15:38:19 | New bug |
Previous Message | Rushabh Lathia | 2008-11-19 11:08:59 | Re: Problem with Bitmap Heap Scan |