Re: Big 7.1 open items - Mailing list pgsql-hackers

From The Hermit Hacker
Subject Re: Big 7.1 open items
Date
Msg-id Pine.BSF.4.21.0006150909030.722-100000@thelab.hub.org
Whole thread Raw
In response to Re: Big 7.1 open items  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
On Wed, 14 Jun 2000, Bruce Momjian wrote:

> > Backtraces from *what*, exactly?  99% of the backend is still going
> > to be dealing with the same data as ever.  It might be that poking
> > around in fd.c will be a little harder, but considering that fd.c
> > doesn't really know or care what the files it's manipulating are
> > anyway, I'm not convinced that this is a real issue.
> 
> I was just throwing gdb out as an example.  The bigger ones are ls,
> lsof/fstat, and tar.

You've lost me on this one ... if someone does an lsof of the process, it
will still provide them a list of open files ... are you complaining about
the extra step required to translate the file name to a "valid table"?  

Oh, one point here ... this whole 'filenaming issue' ... as far as ls is
concerned, at least, only affects the superuser, since he's the only one
that can go 'ls'ng around i nthe directories ...

And, ummm, how hard would it be to have \d in psql display the "physical
table name" as part of its output?

Slight tangent here:

One thing that I think would be great if we could add is some sort of:

SELECT db_name, disk_space;

query wher a database owner, not the superuser, could see how much disk
space their tables are using up ... possible?



pgsql-hackers by date:

Previous
From: The Hermit Hacker
Date:
Subject: Re: Big 7.1 open items
Next
From: "Mark Hollomon"
Date:
Subject: Re: Big 7.1 open items