Re: TODO item inquiry/claim

On 18 Nov 2001 at 18:17 (+0100), Peter Eisentraut wrote:
| Brent Verner writes:
| 
| > * Add table name mapping for numeric file names
| 
| > It's been tested with 7.1 and 7.2bN and is basically a few c functions
| > that allow (approximate) reports of disk usage (in Kb) per database,
| > and  per relation (only on the current database, for now).
| 
| I've written on like that a while ago:
| 
| http://webmail.postgresql.org/~petere/dbsize.html
| 
| The tarball can be rolled into contrib -- now that I think of it I don't
| know why I never did that.
 Can you put your code in contrib?  I've seen atleast a few other 
users wanting to measure disk use.

| Never imagined this would have anything to do with that TODO item, though.
| I figured oid2name accomplished that.
 Yeah, but it address one inconvenience caused by the oid-named files.
Even after reading through the thread[1], I'm not sure what the desired
solution to the problem is.  There seem to be two reasons to know
the filename->(db|rel) mapping.
 1) resource usage [solved] 2) data recovery from db failure.
 Are there any other reasons an admin needs to know the actual
filenames the system is using?  Please reply if you have any.
 I really have no idea what all would be involved in recovering a
database (or a single relation, if possible), so I would appreciate
suggestions on what needs to be done to address this issue WRT the
filename->(db|rel) mappings.  There was not a concensus on what the
proper solution would look like; some suggested maintaining symlinks,
other suggested a separate file of mappings.  If someone would tell
me what a reliable solution would be, I'll work at implementing it
for inclusion in one of the 7.2.X maintenance releases.

cheers. brent

[1] http://fts.postgresql.org/db/mw/msg.html?mid=114680

-- 
"Develop your talent, man, and leave the world something. Records are 
really gifts from people. To think that an artist would love you enough
to share his music with anyone is a beautiful thing."  -- Duane Allman