Horton

Thread

  1. Re: Savepoints

    Vadim Mikheev <vmikheev@sectorbase.com> — 2002-01-23T23:22:42Z

    > 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 -:)

> ...
> 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...

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.

Vadim

  2. Re: Savepoints

    Bruce Momjian <pgman@candle.pha.pa.us> — 2002-01-24T01:08:45Z

    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, Pennsylvania 19026

  3. Re: Savepoints

    Bruce Momjian <pgman@candle.pha.pa.us> — 2002-01-24T01:20:58Z

    > > 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...
> 
> 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.

I am sorry.  I see what you are saying now.  I missed the words
"overwriting smgr".  You are suggesting going to an overwriting storage
manager.  Is this to be done only because of savepoints.  Doesn't seem
worth it when I have a possible solution without such a drastic change.
Also, overwriting storage manager will require MVCC to read through
there to get accurate MVCC visibility, right?

-- 
  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, Pennsylvania 19026

  4. Re: Savepoints

    Don Baccus <dhogaza@pacifier.com> — 2002-01-24T02:05:36Z

    Bruce Momjian wrote:


> I am sorry.  I see what you are saying now.  I missed the words
> "overwriting smgr".  You are suggesting going to an overwriting storage
> manager.


Overwriting storage managers don't suffer from unbounded growth of 
datafiles until garbage collection (vacuum) is performed.  In fact, 
there's no need for a vacuum-style utility.  The rollback segments only 
need to keep around enough past history to rollback transactions that 
are executing.

Of course, then the size of your transactions are limited by the size of 
your rollback segments, which in Oracle are fixed in length when you 
build your database (there are ways to change this when you figure out 
that you didn't pick a good number when creating it).

 >Is this to be done only because of savepoints.

Not in traditional storage managers such as Oracle uses.  The complexity 
of managing visibility and the like are traded off against the fact that 
you're not stuck ever needing to garbage collect a database that 
occupies a roomful of disks.

It's a trade-off.  PG's current storage manager seems to work awfully 
well in a lot of common database scenarios, and Tom's new vacuum is 
meant to help mitigate against the drawbacks.   But overwriting storage 
managers certainly have their advantages, too.

 >  Doesn't seem

> worth it when I have a possible solution without such a drastic change.
> Also, overwriting storage manager will require MVCC to read through
> there to get accurate MVCC visibility, right?


Yep...

-- 
Don Baccus
Portland, OR
http://donb.photo.net, http://birdnotes.net, http://openacs.org

  5. Re: Savepoints

    Hiroshi Inoue <inoue@tpf.co.jp> — 2002-01-24T16:34:29Z

    > -----Original Message-----
> From: Mikheev, Vadim
> 
> 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.
3) We don't need to mind the transaction size so much.

We can't use the db any longer if a REDO recovery fails now.
Under overwriting smgr we can't use the db any longer either
if rollback fails. How could PG be not less reliable than now ?

regards,
Hiroshi Inoue