Re: Savepoints - Mailing list pgsql-hackers

From Mikheev, Vadim
Subject Re: Savepoints
Date
Msg-id 3705826352029646A3E91C53F7189E32518487@sectorbase2.sectorbase.com
Whole thread Raw
In response to Savepoints  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: Savepoints  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
> > 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

And I'm sorry for missing your notes about storing relid+tid only.

> "overwriting smgr". You are suggesting going to an overwriting
> storage manager. Is this to be done only because of savepoints.

No. One point I made a few monthes ago (and never got objections)
is - why to keep old data in data files sooooo long?
Imagine long running TX (eg pg_dump). Why other TX-s must read
again and again completely useless (for them) old data we keep
for pg_dump?

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

Right... just like now non-overwriting smgr requires *ALL*
TX-s to read old data in data files. But with overwriting smgr
TX will read RS only when it is required and as far (much) as
it is required.

Simple solutions are not always the best ones.
Compare Oracle and InterBase. Both have MVCC.
Smgr-s are different. What RDBMS is more cool?
Why doesn't Oracle use more simple non-overwriting smgr
(as InterBase... and we do)?

Vadim


pgsql-hackers by date:

Previous
From: Don Baccus
Date:
Subject: Re: PostgreSQL crashes with Qmail-SQL
Next
From: Don Baccus
Date:
Subject: Re: Savepoints