Re: [HACKERS] Transaction system (proposal for 6.5) - Mailing list pgsql-hackers

---- you wrote:
> On Wed, Sep 16, 1998 at 06:35:53PM -0300, Robson Miranda wrote:
> >     I was thinking in a major rewrite of the PostrgreSQL transaction
> > system, in order to provide less tuple overhead and recoverabilty.

> I do not have much of an idea how postgres handles stuff right now, so
> forgive me if I'm asking stupid questions.
Ok...

> >     My first goal is to reduce tuple overhead, getting rid of xmin/xman and
> > cmin/cmax. To provide this functionality, I'm planning to keep only a
> > flag indicating if the transaction is in curse or not. If, during a
> > transaction, a certain tuple is affected, this flag will store the
> > current transaction id. Thus, if this tuple is commited, an invalid OID
> > (say, 0), will be written to this flag.

> That means you store one flag per tuple? Does this happen only in memory?

There will be something to indicate that the tuple is valid or not. An NULL, for example, can indicate if this tuple is
partof a commited transaction. Any other number indicates that this is an in-progress transaction (an valid transaction
ID).I was thinking in use a unsigned 31 bit for transaction ID and the other bit to flag if this tuple is valid or not.
Thus,an NULL indicates that this line was inserted by a commited xaction, and a number with only the 32nd bit setted
willindicate the this line was deleted by a commited xaction.  
This way, if the xaction rollbacks, the lines inserted will have only the 32nd bit setted, and the delted lines will
haveNULL in this value. But, at commit or rollback, the pages with deleted tuples will have this space added to the
freespace of the page. 
Actualy, there are 2 fields (xmin/xmax) and 4 flags (HEAP_XMIN_COMMITTED, HEAP_XMAX_COMMITTED, HEAP_XMIN_INVALID,
HEAP_XMAX_INVALID)that are used for determine the visibility of a tuple. If a tuple doesn't have these flags setted,
thena test in log relation will be done to determine the correct status of the transaction and then the flags will be
adjusted.These flags operates like a "cache" for the transaction status. Look that these flags can be changed during
selects,and these pages will have to be written to disk after a query. 

> >     The only problem a saw using this approach is if some pages got flushed
> > during the transaction, because these pages will have to be reload from> disk.

> Ah yes, it seems to be in memory only. And you exactly point to one problem.
> Any idea how to solve this?

After looking more deepely in the current transaction model, I think my approach will have a similar performance, since
thesepages will have to be reload only one time (at the end of transaction). Currently, the log pages could be loaded
fromdisk even during a select. 

> >     To keep track of current transactions, there will have a list of tuples
> > affected by this transaction, and the operation executed. This way,
> > during commit, we only confirm these operations in relations (writing an
> > invalid OID in current xid of each tuple affected). To rollback, we
> > delete the new tuples (and mark this operation as a commit) and mark the
> > old tuples affected as "live" (and leave these commited).

> That means we always have both in the relation? That is we write the new
> tuple in and keep the old one? Is this done the same way in the actual
> version? I'd prefer to have a clean cut with new and old not being in the
> same table at the same time.
No, the invalid tuples will be deleted at the end of transaction, freeing the space on the page. I'm thinking in keep
thepage free space in some special blocks inside the table. With pagesize of 8k, I can keep one table of free-space at
every4096 blocks. This way, each table will have the free-space entrys for the 4096 next blocks. 

> >     For recovery (my second goal), I pretend to, at startup of postmaster,
> > to rollback all marked in-curse transactions. After that, I'm thinking
> > about a redo log, but I'm still searching a way to keep it with the
> > minimum size possible.

Where's the problem with a redo log?

I'm still researching how store this information, in order to, during recover, do the right things in the right time,
andto provides on-line backup capability. 


>
> Michael
>

   Robson.


---------------------------------------------------
Get free personalized email at http://www.iname.com