Re: Savepoints
От | Hiroshi Inoue |
---|---|
Тема | Re: Savepoints |
Дата | |
Msg-id | 3C50A807.32A29E09@tpf.co.jp обсуждение исходный текст |
Ответ на | Re: Savepoints ("Mikheev, Vadim" <vmikheev@SECTORBASE.COM>) |
Список | pgsql-hackers |
"Mikheev, Vadim" wrote: > > > > How about: use overwriting smgr + put old records into rollback > > > segments - RS - (you have to keep them somewhere till TX's running > > > anyway) + use WAL only as REDO log (RS will be used to rollback TX' > > > changes and WAL will be used for RS/data files recovery). > > > Something like what Oracle does. > > > > As long as we use no overwriting manager > > 1) Rollback(data) isn't needed in case of a db crash. > > 2) Rollback(data) isn't needed to cancal a transaction entirely. > > -1) But vacuum must read a huge amount of data to remove dirt. > -2) But TX-s must read data they are not interested at all. > > > 3) We don't need to mind the transaction size so much. > > -3) The same with overwriting smgr and WAL used *only as REDO log*: The larger RS becomes the longer it would take time to cancel the transaction whereas it is executed in a momemnt under no overwriting smgr and for example if RS exhausted all disk space is PG really safe ? Other backends would also fail because they couldn't write RS any mode. Many transactions would execute UNDO operations simultaneously but there's no space to write WALs (UNDO operations must be written to WAL also) and PG system would abort. And could PG restart under such situations ? Even though there's a way to recover from the situation, I think we should avoid such dangerous situations from the first. Basically recovery operations should never fail. > > > We can't use the db any longer if a REDO recovery fails now. > > Reset WAL and use/dump it. Annoying? Agreed. Fix bugs and/or > use good RAM - whatever caused problem with restart. As I already mentioned recovery operations should never fail. > > > Under overwriting smgr we can't use the db any longer either > > if rollback fails. > > Why should it fail? Bugs? Fix them. Rollback operations are executed much more often than REDO recovery and it is hard to fix such bugs once PG was released. Most people in such troubles have no time to persue the cause. In reality I replied to the PG restart troubles twice (with --wal-debug and pg_resetxlog suggestions ) in Japan but got no further replies. > > > How could PG be not less reliable than now ? > > Is today' RG more reliable than Oracle, Informix, DB2? I have never been and would never be optiomistic about recovery. Is 7.1 more reliable than 7.0 from the recovery POV ? I see no reason why overwriting smgr is more relaible than no overwriting smgr as for recovery. regards, Hiroshi Inoue
В списке pgsql-hackers по дате отправления: