| |
| Data Integrity |
| |
| PostgreSQL provides many advanced features to preserve the integrity of your data. The
following list describes these features: |
| |
| Write Ahead Logging (WAL) |
| This new feature enables automatic recovery of databases following a system crash. The
central concept behind WAL is that changes to files will be written only after those changes
have been written to a physical database log. After the data is committed to disk, the
corresponding log records are updated to indicate that transactions have been physically
committed. Thus, the physical log provides a mechanism for recovering your database in the
event of a disk failure. |
| |
| Multi-Version Concurrency Control |
| Exclusive Multi-version concurrency control (MVCC) system, for high demanding concurrent
applications. In this unique mechanism readers do not block writers and writers do not block
readers, reducing (sometimes eliminating) concurrent transaction contention and deadlocks. |
| |
| Transaction Logging |
| In addition to being written to the target database, modifying transactions (Inserts,
Deletes, and Updates) are also written to a log file. This duplication allows transactions
to be recovered (repeated) following an abnormal shutdown of the database. Logging thus reduces
the possibility of losing data in the event of a power interruption or hardware failure. |
| |
| Commit/Rollback |
| Certain database functions require the grouping of transactions such that if any part
of a function fails, the entire function fails. An example would be the transfer of money
from one account to another; if the deposit (insert) fails, the previous withdrawal (update)
needs to be backed out as if it never happened. PostgreSQL supports this concept with the
implementation of Commit and Rollback. Transactions can be isolated in such a way that they
can all be rolled back in the event of a failure of any of the other isolated transactions. |
| |
| Checkpoints |
| A database achieves a great deal of its speed by caching individual transactions in
high-speed Random Access Memory (RAM) and later writing them, en masse, to disk. Although
caching transactions to RAM improves speed, it is risky in that RAM is not persistent memory
and its contents can be lost in the event of a power outage or hardware failure. A “checkpoint”
forces all completed transactions to be written from RAM to disk, which is a persistent (safe)
storage device. PostgreSQL supports checkpointing which helps to ensure the integrity of the
data within the database. |
| |
| Triggers |
| Triggers are user-written procedures which can be configured to fire off in the event
of a transaction against a table. Typically triggers are used to ensure referential integrity
(consistency) between tables in a database. |
| |
| Constraints |
| In addition to referential integrity as enforced through the use of triggers, PostgreSQL
also supports Declarative Referential Integrity (DRI) as enforced by constraints placed on a
table when it is created. This ensures that every child record has a parent record in another
table and prevents orphaned records with no relationship to data anywhere else in the database. |
| |
| On-line Backup |
| PostgreSQL allows for on-line, or “hot” backups. Hot backups can be run without users
having to log out of the database. This allows for archiving a database without any disruption
to those using the database. |
| |
| |