Re: Big 7.1 open items

Bruce Momjian wrote:
> >
> >         DESCRIBE TABLE/VIEW/whatnot <object-name>
> >
> >     that returns the physical location and storage details of the
> >     object. And psql could use it to print this  info  additional
> >     on  the  \d commands. Would give unprivileged users access to
> >     this info, so be it, it's not a security issue IMHO.
>
> You need something that works from the command line, and something that
> works if PostgreSQL is not running.  How would you restore one file from
> a tape.  I guess you could bring back the whole thing, then do the
> query, and move the proper table file back in, but that is a pain.
   Think you messed up some basics of PG here.
   It's  totally useless to restore single files of a PostgreSQL   database. You could either put back anything below
./data,or   nothing - the reason is pg_log.
 
   You  don't  need  something  that work's if PostgreSQL is not   running.  You cannot restore ONE file from a  tape!
You can   restore  a  PostgreSQL  instance (only a complete one - not a   single DB, nor a single table or any  other
object).  While   your  backup  is writing to the tape, each number of backends   could concurrently modify single
blocks of  the  heap,  it's   indices and pg_log. So what does the tape contain the?
 
   I'd  like  to ask you, are you sure the backups you're making   are worth the power consumption of  the  tape
drive? You're   talking  about  restoring  a file - and sould be aware of the   fact, that any file based backup would
neverbe able  to  get   consistent snapshot of the database, like pg_dump is able to.
 
   As long as you don't take  the  postmaster  down  during  the   entire  saving  of ./data, you aren't in a safe
position.And   the only safe RESTORE is  to  restore  ./data  completely  or   nothing.  It's  not  even  (easily)
possible to  initdb and   restore a single DB from tape (it is, but requires some  deep   knowledge and more than just
restoringsome files from tape).
 
   YOU REALLY DON'T NEED ANY FILENAMES IN THERE!
   The more I think about it, the more I feel these file  names,   easily associatable with the objects they represent,
aremore   dangerous than useful in practice. Maybe we should  obfuscate   the  entire  ./data  like  Oracle  does  with
it'stablespace   files.  Just  that  our  tablespaces  will  be   directories,   containing totally cryptic named
files.


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #