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.
> 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?
> 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?
> 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.
> 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?
Michael
--
Dr. Michael Meskes | Th.-Heuss-Str. 61, D-41812 Erkelenz | Go SF49ers!
Senior-Consultant | business: Michael.Meskes@mummert.de | Go Rhein Fire!
Mummert+Partner | private: Michael.Meskes@usa.net | Use Debian
Unternehmensberatung AG | Michael.Meskes@gmx.net | GNU/Linux!