From: Markus Schaber <schabi@logix-tt.com>
To: PostgreSQL SQL List <pgsql-sql@postgresql.org>
Subject: Re: Migrating a Database to a new tablespace
Date: Thu, 27 Apr 2006 11:09:24 +0200
Message-ID: <44508A44.4090909@logix-tt.com> (raw)
In-Reply-To: <200604261635.k3QGZdB06325@candle.pha.pa.us>
References: <200604261635.k3QGZdB06325@candle.pha.pa.us>
Hi, Bruce,
Bruce Momjian wrote:
> I have work someone did in the past. I just need to be updated to deal
> with tablespaces.
>
> ftp://candle.pha.pa.us/pub/postgresql/mypatches/checkfile.*
>
> Let me know if you want details.
It looks nice, but I would not like automatic deletion (or only optional
or configurable), there might be valid reasons for "alien" files to
exist. (README files for admins to communicate what this directory is
used for, MacOS ressource forks, Reiser4 special files etc...)
What about putting the identification code in a set returning function
or view that can be called by the admin. Then tools like nagios can call
it and ring the alarm bells when unknown files appear, or possibly
autovacuum calls it once on each session to generate log warnings.
Btw, are CLUSTER and ALTER TABLE ALTER COLUMN statements that "create or
drop a relation" in this sense? And what is with tables getting extended
to more than one file?
Another idea would be to first create and sync log entries about the
files to be created / deleted, and then actually create / delete the
files. So on log replay, the backend could watch out for file operations
from transactions that never completed. It will slow those operations
down, but such file operations are both seldom and relatively expensive
on most filesystems. And it does not help in case of fsync=off, but
those admins already take worse risks than wasting disk space.
Thanks,
Markus
--
Markus Schaber | Logical Tracking&Tracing International AG
Dipl. Inf. | Software Development GIS
Fight against software patents in EU! www.ffii.org www.nosoftwarepatents.org
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-sql@postgresql.org
Cc: schabi@logix-tt.com
Subject: Re: Migrating a Database to a new tablespace
In-Reply-To: <44508A44.4090909@logix-tt.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox