begriffs open source - ai-pg/blob - full-docs/txt/wal-async-commit.txt

   1
   2 28.4. Asynchronous Commit #
   3
   4    Asynchronous commit is an option that allows transactions to complete
   5    more quickly, at the cost that the most recent transactions may be lost
   6    if the database should crash. In many applications this is an
   7    acceptable trade-off.
   8
   9    As described in the previous section, transaction commit is normally
  10    synchronous: the server waits for the transaction's WAL records to be
  11    flushed to permanent storage before returning a success indication to
  12    the client. The client is therefore guaranteed that a transaction
  13    reported to be committed will be preserved, even in the event of a
  14    server crash immediately after. However, for short transactions this
  15    delay is a major component of the total transaction time. Selecting
  16    asynchronous commit mode means that the server returns success as soon
  17    as the transaction is logically completed, before the WAL records it
  18    generated have actually made their way to disk. This can provide a
  19    significant boost in throughput for small transactions.
  20
  21    Asynchronous commit introduces the risk of data loss. There is a short
  22    time window between the report of transaction completion to the client
  23    and the time that the transaction is truly committed (that is, it is
  24    guaranteed not to be lost if the server crashes). Thus asynchronous
  25    commit should not be used if the client will take external actions
  26    relying on the assumption that the transaction will be remembered. As
  27    an example, a bank would certainly not use asynchronous commit for a
  28    transaction recording an ATM's dispensing of cash. But in many
  29    scenarios, such as event logging, there is no need for a strong
  30    guarantee of this kind.
  31
  32    The risk that is taken by using asynchronous commit is of data loss,
  33    not data corruption. If the database should crash, it will recover by
  34    replaying WAL up to the last record that was flushed. The database will
  35    therefore be restored to a self-consistent state, but any transactions
  36    that were not yet flushed to disk will not be reflected in that state.
  37    The net effect is therefore loss of the last few transactions. Because
  38    the transactions are replayed in commit order, no inconsistency can be
  39    introduced — for example, if transaction B made changes relying on the
  40    effects of a previous transaction A, it is not possible for A's effects
  41    to be lost while B's effects are preserved.
  42
  43    The user can select the commit mode of each transaction, so that it is
  44    possible to have both synchronous and asynchronous commit transactions
  45    running concurrently. This allows flexible trade-offs between
  46    performance and certainty of transaction durability. The commit mode is
  47    controlled by the user-settable parameter synchronous_commit, which can
  48    be changed in any of the ways that a configuration parameter can be
  49    set. The mode used for any one transaction depends on the value of
  50    synchronous_commit when transaction commit begins.
  51
  52    Certain utility commands, for instance DROP TABLE, are forced to commit
  53    synchronously regardless of the setting of synchronous_commit. This is
  54    to ensure consistency between the server's file system and the logical
  55    state of the database. The commands supporting two-phase commit, such
  56    as PREPARE TRANSACTION, are also always synchronous.
  57
  58    If the database crashes during the risk window between an asynchronous
  59    commit and the writing of the transaction's WAL records, then changes
  60    made during that transaction will be lost. The duration of the risk
  61    window is limited because a background process (the “WAL writer”)
  62    flushes unwritten WAL records to disk every wal_writer_delay
  63    milliseconds. The actual maximum duration of the risk window is three
  64    times wal_writer_delay because the WAL writer is designed to favor
  65    writing whole pages at a time during busy periods.
  66
  67 Caution
  68
  69    An immediate-mode shutdown is equivalent to a server crash, and will
  70    therefore cause loss of any unflushed asynchronous commits.
  71
  72    Asynchronous commit provides behavior different from setting fsync =
  73    off. fsync is a server-wide setting that will alter the behavior of all
  74    transactions. It disables all logic within PostgreSQL that attempts to
  75    synchronize writes to different portions of the database, and therefore
  76    a system crash (that is, a hardware or operating system crash, not a
  77    failure of PostgreSQL itself) could result in arbitrarily bad
  78    corruption of the database state. In many scenarios, asynchronous
  79    commit provides most of the performance improvement that could be
  80    obtained by turning off fsync, but without the risk of data corruption.
  81
  82    commit_delay also sounds very similar to asynchronous commit, but it is
  83    actually a synchronous commit method (in fact, commit_delay is ignored
  84    during an asynchronous commit). commit_delay causes a delay just before
  85    a transaction flushes WAL to disk, in the hope that a single flush
  86    executed by one such transaction can also serve other transactions
  87    committing at about the same time. The setting can be thought of as a
  88    way of increasing the time window in which transactions can join a
  89    group about to participate in a single flush, to amortize the cost of
  90    the flush among multiple transactions.