Buffered transaction logging
If transactions are made against a database that uses buffered
logging, the records are held (buffered) in the logical-log
buffer for as long as possible. They are not flushed from the logical-log
buffer in shared memory to the logical log on disk until one of the
following situations occurs:
- The buffer is full.
- A commit on a database with unbuffered logging flushes the buffer.
- A checkpoint occurs.
- The connection is closed.
If you use buffered logging and a failure occurs, you cannot expect the database server to recover the transactions that were in the logical-log buffer when the failure occurred. Thus, you might lose some committed transactions. In return for this risk, performance during alterations improves slightly. Buffered logging is best for databases that are updated frequently (when the speed of updating is important), as long as you can recreate the updates in the event of failure. You can tune the size of the logical-log buffer to find an acceptable balance for your system between performance and the risk of losing transactions to system failure.