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(at)Yahoo(dot)com #