Home • Explore • Blog • CI
☰



postgresql
2nd chunk of `doc/src/sgml/glossary.sgml`
a0d08bee844dd3747d5ffbdf5109fc87dccb3ba2c9c52e740000000100000fa4
 (<acronym>AIO</acronym>) describes
     performing <acronym>I/O</acronym> in a non-blocking way (asynchronously),
     in contrast to synchronous <acronym>I/O</acronym>, which blocks for the
     entire duration of the <acronym>I/O</acronym>.
    </para>
    <para>
     With <acronym>AIO</acronym>, starting an <acronym>I/O</acronym> operation
     is separated from waiting for the result of the operation, allowing
     multiple <acronym>I/O</acronym> operations to be initiated concurrently,
     as well as performing <acronym>CPU</acronym> heavy operations
     concurrently with <acronym>I/O</acronym>. The price for that increased
     concurrency is increased complexity.
    </para>
    <glossseealso otherterm="glossary-io" />
   </glossdef>
  </glossentry>

  <glossentry id="glossary-atomic">
   <glossterm>Atomic</glossterm>
   <glossdef>
    <para>
     In reference to a <glossterm linkend="glossary-datum">datum</glossterm>:
     the fact that its value cannot be broken down into smaller
     components.
    </para>
   </glossdef>
   <glossdef>
    <para>
     In reference to a
     <glossterm linkend="glossary-transaction">database transaction</glossterm>:
     see <glossterm linkend="glossary-atomicity">atomicity</glossterm>.
    </para>
   </glossdef>
  </glossentry>

  <glossentry id="glossary-atomicity">
   <glossterm>Atomicity</glossterm>
   <glossdef>
    <para>
     The property of a <glossterm linkend="glossary-transaction">transaction</glossterm>
     that either all its operations complete as a single unit or none do.
     In addition, if a system failure occurs during the execution of a
     transaction, no partial results are visible after recovery.
     This is one of the <acronym>ACID</acronym> properties.
    </para>
   </glossdef>
  </glossentry>

  <glossentry id="glossary-attribute">
   <glossterm>Attribute</glossterm>
   <glossdef>
    <para>
     An element with a certain name and data type found within a
     <glossterm linkend="glossary-tuple">tuple</glossterm>.
    </para>
   </glossdef>
  </glossentry>

  <glossentry id="glossary-autovacuum">
   <glossterm>Autovacuum (process)</glossterm>
   <glossdef>
    <para>
     A set of background processes that routinely perform
     <glossterm linkend="glossary-vacuum">vacuum</glossterm>
     and <glossterm linkend="glossary-analyze">analyze</glossterm> operations.
     The <glossterm linkend="glossary-auxiliary-proc">auxiliary process</glossterm>
     that coordinates the work and is always present (unless autovacuum
     is disabled) is known as the <firstterm>autovacuum launcher</firstterm>,
     and the processes that carry out the tasks are known as the
     <firstterm>autovacuum workers</firstterm>.
    </para>
    <para>
     For more information, see
     <xref linkend="autovacuum"/>.
    </para>
   </glossdef>
  </glossentry>

  <glossentry id="glossary-auxiliary-proc">
   <glossterm>Auxiliary process</glossterm>
   <glossdef>
    <para>
     A process within an <glossterm linkend="glossary-instance">instance</glossterm>
     that is in charge of some specific background task for the instance.
     The auxiliary processes consist of <!-- in alphabetical order -->
     <!-- NB: In the code, the autovac launcher doesn't use the auxiliary
          process scaffolding; however it does behave as one so we list it
          here anyway. In addition, logger isn't connected to shared memory so
          most code outside postmaster.c doesn't even consider it a "proc" in
          the first place.
          -->
     the <glossterm linkend="glossary-autovacuum">autovacuum launcher</glossterm>
     (but not the autovacuum workers),
     the <glossterm linkend="glossary-background-writer">background writer</glossterm>,
     the <glossterm linkend="glossary-checkpointer">checkpointer</glossterm>,
     the <glossterm linkend="glossary-logger">logger</glossterm>,
     the <glossterm linkend="glossary-startup-process">startup process</glossterm>,
     the <glossterm
Title: Asynchronous I/O and Atomic Operations in PostgreSQL
Summary
This section explains two important concepts in PostgreSQL: Asynchronous I/O (AIO) and atomic operations. AIO is described as a non-blocking method of performing I/O operations, allowing for concurrent execution of multiple I/O tasks and CPU-heavy operations. The text also defines 'atomic' in two contexts: for data, meaning it cannot be broken down further, and for database transactions, referring to the property of atomicity. Atomicity ensures that all operations in a transaction are completed as a single unit or none at all, even in the event of system failures.