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 never be 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 restoring some 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, are more
    dangerous than useful in practice. Maybe we should  obfuscate
    the  entire  ./data  like  Oracle  does  with it's tablespace
    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 #