Re: Savepoints
От | Bruce Momjian |
---|---|
Тема | Re: Savepoints |
Дата | |
Msg-id | 200201240108.g0O18jV26044@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: Savepoints ("Mikheev, Vadim" <vmikheev@SECTORBASE.COM>) |
Список | pgsql-hackers |
Mikheev, Vadim wrote: > > I have talked in the past about a possible implementation of > > savepoints/nested transactions. I would like to more formally outline > > my ideas below. > > Well, I would like to do the same -:) Good. > > ... > > There is no reason for other backend to be able to see savepoint undo > > information, and keeping it private greatly simplifies the > > implementation. > > Yes... and requires additional memory/disk space: we keep old records > in data files and we'll store them again... I was suggesting keeping only relid/tid or in some cases only relid. Seems like one or the other will fit all needs: relid/tid for update of a few rows, relid for many rows updated in the same table. I saw no need to store the actual data. > 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. Why record the old data rows rather than the tids? While the transaction is running, the rows can't be moved anyway. Also, why store them in a shared area. That has additional requirements because one old transaction can require all transactions to keep their stuff around. Why not just make it a private data file for each backend? -- 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
В списке pgsql-hackers по дате отправления: