From: | "Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)au> |
---|---|
To: | "Hackers" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Firebird 1.0 released |
Date: | 2002-04-16 04:35:52 |
Message-ID: | GNELIHDDFBOCMGBFGEFOGECHCCAA.chriskl@familyhealth.com.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
The Firebird guys have gotten around to releasing 1.0. If you read this
front page spiel, you'll notice that they use MVCC, but with an overwriting
storage manager.
http://www.ibphoenix.com/ibp_act_db.html
The relevant extract:
"Multi-version concurrency control uses back versions of modified and
deleted records to maintain a consistent view of data for read transactions.
Each record version is tagged with the identifier of the transaction that
created it. When a record is modified, the old version of the record is
reduced to a "delta record" - a set of differences from the new version -
and written to a new location, ordinarily on the same page where it was
originally stored. Then the new record overwrites the old. The new record
points to the old record. Unless the values of indexed fields are changed,
there's no need to update the index. Even if the values have changed, the
old values remain in the index to keep the record available to older
transactions.
The transaction identifier also permits update transactions to recognize
updates by concurrent transactions and allows Firebird to dispense with
write locks on records. When a transaction encounters a record updated by a
concurrent transaction, it waits for the other transaction to complete. If
the competing transaction commits, the waiting transaction gets an error. If
the competing transaction rolls back, the waiting transaction succeeds. If
the competing transaction attempts to update a record that the waiting
transaction has modified, a deadlock exists and one or the other will
receive an error.
Multi-version concurrency replaces a before-image (rollback) log with
versions stored in the database. When a transaction fails, its changes
remain in the database. The next transaction that reads that record
recognizes that the record version is invalid. Depending on the version of
Firebird and architecture, that transaction either replaces the invalid
record version with its back version or invokes a garbage collect thread. "
Chris
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2002-04-16 04:36:11 | Re: [PATCHES] [SQL] 16 parameter limit |
Previous Message | Tom Lane | 2002-04-16 04:34:02 | Re: multibyte support by default |