Обсуждение: AW: Plans for solving the VACUUM problem
> >If community will not like UNDO then I'll probably try to implement > >dead space collector which will read log files and so on. > > I'd vote for UNDO; in terms of usability & friendliness it's a big win. Could you please try it a little more verbose ? I am very interested in the advantages you see in "UNDO for rollback only". pg_log is a very big argument, but couldn't we try to change the format to something that only stores ranges of aborted txn's in a btree like format ? Now that we have WAL, that should be possible. Andreas
At 11:25 23/05/01 +0200, Zeugswetter Andreas SB wrote: > >> >If community will not like UNDO then I'll probably try to implement >> >dead space collector which will read log files and so on. >> >> I'd vote for UNDO; in terms of usability & friendliness it's a big win. > >Could you please try it a little more verbose ? I am very interested in >the advantages you see in "UNDO for rollback only". I have not been paying strict attention to this thread, so it may have wandered into a narrower band than I think we are in, but my understanding is that UNDO is required for partial rollback in the case of failed commands withing a single TX. Specifically, - A simple typo in psql can currently cause a forced rollback of the entire TX. UNDO should avoid this. - It is not uncommon for application in other databases to handle errors from the database (eg. missing FKs), and continue a TX. - Similarly, when we get a new error reporting system, general constraint (or other) failures should be able to be handled in one TX. ---------------------------------------------------------------- Philip Warner | __---_____ Albatross Consulting Pty. Ltd. |----/ - \ (A.B.N. 75 008 659 498) | /(@) ______---_ Tel: (+61) 0500 83 82 81 | _________ \ Fax: (+61) 0500 83 82 82 | ___________ | Http://www.rhyme.com.au | / \| | --________-- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/
> >> I'd vote for UNDO; in terms of usability & friendliness it's a big win. > > > >Could you please try it a little more verbose ? I am very interested in > >the advantages you see in "UNDO for rollback only". The confusion here is that you say you want UNDO, but then say you want it to happen in the background, which sounds more like autovacuum than UNDO. > I have not been paying strict attention to this thread, so it may have > wandered into a narrower band than I think we are in, but my understanding > is that UNDO is required for partial rollback in the case of failed > commands withing a single TX. Specifically, > > - A simple typo in psql can currently cause a forced rollback of the entire > TX. UNDO should avoid this. > > - It is not uncommon for application in other databases to handle errors > from the database (eg. missing FKs), and continue a TX. > > - Similarly, when we get a new error reporting system, general constraint > (or other) failures should be able to be handled in one TX. I think what you are asking for here is subtransactions, which can be done without UNDO if we assign a unique transaction id's to each subtransaction. Not pretty, but possible. UNDO makes subtransactions easier because you can UNDO the part that failed. However, someone mentioned you may have to wait for that part to be undone. I think you have to wait because the current transaction would have no way to know which rows were visible to the current transaction unless you mark them right away or grope through the WAL every time you visit a tuple. -- Bruce Momjian | http://candle.pha.pa.us 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
> > - A simple typo in psql can currently cause a forced > > rollback of the entire TX. UNDO should avoid this. > > Yes, I forgot to mention this very big advantage, but undo is > not the only possible way to implement savepoints. Solutions > using CommandCounter have been discussed. This would be hell. Vadim