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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Big 7.1 open items
Следующее
От: Karel Zak
Дата:
Сообщение: Re: Big 7.1 open items