Re: TODO item inquiry/claim
От | Bruce Momjian |
---|---|
Тема | Re: TODO item inquiry/claim |
Дата | |
Msg-id | 200202222306.g1MN6Ce04399@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: TODO item inquiry/claim (Brent Verner <brent@rcfile.org>) |
Список | pgsql-hackers |
Brent Verner wrote: > 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. Done. > | 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] Yes. > 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. I wish I knew the answer. :-) -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
В списке pgsql-hackers по дате отправления: