AW: Big 7.1 open items
От | Zeugswetter Andreas SB |
---|---|
Тема | AW: Big 7.1 open items |
Дата | |
Msg-id | 219F68D65015D011A8E000006F8590C604AF7DE4@sdexcsrv1.f000.d0188.sd.spardat.at обсуждение исходный текст |
Список | pgsql-hackers |
> 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. 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
В списке pgsql-hackers по дате отправления: