AW: Big 7.1 open items

> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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.

From what I know it is possible to simply restore one table file
since pg_log keeps all tid's. Of course it cannot guarantee integrity
and does not work if the table was altered.

> 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.

In the last proposal Bruce and I had it all layed out for tabname + oid
with no overhead in the normal situation, and little overhead if a rename
table crashed or was not rolled back or committed properly
which imho had all advantages combined.

Andreas