Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] Transaction system (proposal for 6.5)

From: The Hermit Hacker <scrappy(at)hub(dot)org>
To: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>
Cc: Robson Miranda <rmiranda(at)rudah(dot)com(dot)br>, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] Transaction system (proposal for 6.5)
Date: 1998-09-21 06:02:16
Message-ID: Pine.BSF.4.02.9809210258210.385-100000@thelab.hub.org (view raw or flat)
Thread:
Lists: pgsql-hackers
On Sun, 20 Sep 1998, Bruce Momjian wrote:

> > Hi...
> > 
> >  
> > 	I was thinking in a major rewrite of the PostrgreSQL transaction
> > system, in order to provide less tuple overhead and recoverabilty.
> > 
> > 	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.
> > 
> > 	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.
> > 
> > 	To address the problem of non-functional update, I pretend to store a
> > command identifier with the tuple, and, during update, see if the cid of
> > a tuple is equal of the current cid of this transaction (like we do
> > today).
> > 
> > 	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).
> > 
> > 	I'm thinking of leave a transaction id for each new backend, and
> > postmaster will keep track of used transaction ids. This way, there is
> > no need to keep a list of transactions in shared memory.
> > 
> > 	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. 
> 
> 
> Interesting.  I know we have talked in the past about the various system
> columns and their removal.  If you check the hackers archive under cmin,
> etc, I think you will find some discussion.
> 
> Now, as far as their removal, is it worth removing 8 bytes of tuple
> overhead for the gain of having to do a redo log, etc.  I am not sure. 
> I know many commercial databases have it, but I am not sure how
> benificial it would be.

	I may be missing something in the original posting that you are
seeing, but I don't see the two as necesarily being inter-related...my
understanding of the Oracle redo logs is that if a database corrupts, you
can rebuild it from the last backup + the redo logs to get to the same
point as where the corruption happened...

> What I would really like is the ability to re-use superceeded tuples
> without vacuum.  It seems that should be possible, but it has not been
> done by anyone yet.  That would be a HUGE win, I think.

	Not sure, but IMHO, having a redo log capability would be a HUGE
win also...consider a mission critical application that doesn't have, in
essence, "live backups" in the form of a redo log...

Marc G. Fournier                                
Systems Administrator @ hub.org 
primary: scrappy(at)hub(dot)org           secondary: scrappy(at){freebsd|postgresql}.org 


In response to

Responses

pgsql-hackers by date

Next:From: The Hermit HackerDate: 1998-09-21 06:04:45
Subject: Re: [HACKERS] Version numbers (was Re: [PATCHES] Several libpgtcl fixes)
Previous:From: The Hermit HackerDate: 1998-09-21 05:55:30
Subject: Re: My patches

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group