Re: Big 7.1 open items

> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > 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.
> 
> "Restore one file from a tape"?  How are you going to do that anyway?
> You can't save and restore portions of a database like that, because
> of transaction commit status problems.  To restore table X correctly,
> you'd have to restore pg_log as well, and then your other tables are
> hosed --- unless you also restore all of them from the backup.  Only
> a complete database restore from tape would work, and for that you
> don't need to tell which file is which.  So the above argument is a
> red herring.
> 
> I realize it's nice to be able to tell which table file is which by
> eyeball, but the price we are paying for that small convenience is
> just too high.  Give that up, and we can have rollbackable DROP and
> RENAME now (I'll personally commit to making it happen for 7.1).
> Continue to insist on it, and I don't think we'll *ever* have those
> features in a really robust form.  It's just not possible to do
> multiple file renames atomically.
> 

OK, I am flexible.  (Yea, right.)  :-)

But seriously, let me give some background.  I used Ingres, that used
the VMS file system, but used strange sequential AAAF324 numbers for
tables.  When someone deleted a table, or we were looking at what tables
were using disk space, it was impossible to find the Ingres table names
that went with the file.  There was a system table that showed it, but
it was poorly documented, and if you deleted the table, there was no way
to look on the tape to find out which file to restore.

As far as pg_log, you certainly would not expect to get any information
back from the time of the backup table to current, so the current pg_log
would be just fine.

Basically, I guess we have to do it, but we have to print the proper
error messages for cases in the backend we just print the file name. 
Also, we have to now replace the 'ls -l' command with something that
will be meaningful.

Right now, we use 'ps' with args to display backend information, and ls
-l to show disk information.  We are going to lose that here.



--  Bruce Momjian                        |  http://www.op.net/~candle 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