| Lists: | pgsql-hackerspgsql-patches |
|---|
| From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
|---|---|
| To: | PostgreSQL-patches <pgsql-patches(at)postgresql(dot)org> |
| Subject: | Removing unreferenced files |
| Date: | 2006-06-08 15:08:05 |
| Message-ID: | 200606081508.k58F85m29270@candle.pha.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Lists: | pgsql-hackers pgsql-patches |
Here is a cleaned-up version of the unreference file patch that was
discussed extensively in May of 2005. I want to get it into the
archives in case someone else want to work on it.
Here is a reference to the work still needed on the patch:
http://archives.postgresql.org/pgsql-patches/2005-05/msg00024.php
--
Bruce Momjian http://candle.pha.pa.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
| Attachment | Content-Type | Size |
|---|---|---|
| /pgpatches/checkfiles.diff | text/x-diff | 8.5 KB |
| From: | Alex Shulgin <ash(at)commandprompt(dot)com> |
|---|---|
| To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
| Cc: | <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Removing unreferenced files |
| Date: | 2014-11-18 16:58:12 |
| Message-ID: | 87lhn8monv.fsf@commandprompt.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Lists: | pgsql-hackers pgsql-patches |
Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
>
> Here is a cleaned-up version of the unreference file patch that was
> discussed extensively in May of 2005. I want to get it into the
> archives in case someone else want to work on it.
>
> Here is a reference to the work still needed on the patch:
>
> http://archives.postgresql.org/pgsql-patches/2005-05/msg00024.php
Hello,
This is a TODO item, but I'd like to know if there's general interest in
this feature at the moment.
I think it can be useful in a situation when the DBA knows that the
database was shutdown or crashed during extensive data load and has a
way to proceed without the need to start over with the clean database.
In such a case having a tool to report or remove any stale files makes
perfect sense.
My other concern is that if at some point there is a bug in DROP
TABLE/INDEX that leaves the files it's supposed to remove, we would
likely want to know it.
Regardless of the outcome of this discussion it is interesting to know
if such functionality can only be programmed in backend/startup or
making it a separate tool is feasible (the tool will only run with the
stopped server)? There was once a tool named pgfsck[1], which was never
updated after 8.2, so the name is already taken...
Yet another point is that one might be interested not only in reporting
stale files, but any *missing* ones too. Currently, you would only know
if a relation data file is missing when actually trying to read from it
and no attempt is made to verify this on startup. This might be not a
very useful check since if the file is not missing, but corrupted the
check doesn't buy you much. (I am likely kicking a dead horse here.)
Thank you.
--
Alex