s/Postgres/PostgreSQL/g

1 files changed, 14 insertions, 14 deletions

diff --git a/taler-auditor-manual.rst b/taler-auditor-manual.rst
index cf3952f8..e7aecb84 100644
--- a/taler-auditor-manual.rst
+++ b/taler-auditor-manual.rst
@@ -65,7 +65,7 @@ all, the goal is to detect nerfarious activity of the exchange operator,
 which cannot be effectively done on a machine controlled by the exchange
 operator.
 
-For this, every auditor needs to operate a Postgres database.  The data
+For this, every auditor needs to operate a PostgreSQL database.  The data
 collected will include sensitive information about Taler users, including
 withdrawals made by consumers and income received by merchants.  As a result,
 the auditor is expected to provide high confidentiality for the database.  In
@@ -118,7 +118,7 @@ third parties to verify one's own work.
 The Taler software stack for an auditor consists of the following
 components:
 
--  DBMS: Postgres
+-  DBMS: PostgreSQL
 
    The auditor requires a DBMS to store a local copy of the transaction history for
    the Taler exchange, as well as for its own internal bookkeeping and checkpointing.
@@ -128,7 +128,7 @@ components:
    concern that must be addressed manually.  The software only verifies the content
    of a well-formed exchange database (well-formed with respect to SQL).
    For now, the GNU Taler reference implementation
-   only supports Postgres, but the code could be easily extended to
+   only supports PostgreSQL, but the code could be easily extended to
    support another DBMS.
 
 -  The auditor Web service
@@ -268,7 +268,7 @@ Additionally, there are two canonical system users of relevance (which your
 distribution would typically create for you):
 
   * www-data --- runs the HTTPS frontend (usually nginx or Apache)
-  * postgres --- runs the Postgres database
+  * postgres --- runs the PostgreSQL database
 
 
 Databases and users
@@ -585,7 +585,7 @@ as illustrated in the following figure:
 
 .. image:: replication.png
 
-First, the exchange should use standard Postgres replication features to
+First, the exchange should use standard PostgreSQL replication features to
 enable the auditor to obtain a full copy of the exchange's database.
 Second, the auditor should make a "trusted" local copy, ensuring that it
 never replicates malicious changes using ``taler-auditor-sync``. Both
@@ -595,7 +595,7 @@ We note that as a result of these steps, the auditor will have three
 databases: its own production primary database (as configured in
 ``auditordb-postgres``), its on production copy of the exchange's database
 (``exchangedb-postgress``), and a third, untrusted "ingres" copy of the
-exchange database.  The untrusted database should run as a separate Postgres
+exchange database.  The untrusted database should run as a separate PostgreSQL
 instance and is only accessed via ``taler-auditor-sync`` and the replication
 mechanism driven by the exchange operator.
 
@@ -607,7 +607,7 @@ Ingres operation should be done using the ``auditor-ingres`` user --- or
 depending on the setup parts of the operation may be done by the ``postgres``
 user directly.
 
-The full copy can be obtained in various ways with Postgres.  It is
+The full copy can be obtained in various ways with PostgreSQL.  It is
 possible to use log shipping with streaming replication as described
 in https://www.postgresql.org/docs/13/warm-standby.html, or to use
 logical replication, as described in
@@ -616,7 +616,7 @@ that asynchronous replication should suffice.
 
 The resulting auditor database should be treated as read-only on the auditor
 side.  The ``taler-exchange-dbinit`` tool can be used to setup the schema, or
-the schema can be replicated using Postgres's standard mechanisms. The same
+the schema can be replicated using PostgreSQL's standard mechanisms. The same
 applies for schema upgrades: if logical replication is used (which does not
 replicate schema changes), ``taler-exchange-dbinit`` can be used to migrate
 the schema(s) in both the ingres and production copies of the exchange's
@@ -640,7 +640,7 @@ Wireguard.
 It is also necessary to edit ``main.cf`` of the exchange and on the auditor
 side to enable logical replication.  If an exchange has multiple auditors, it
 should setup multiple ``egress`` accounts.  The exchange must ensure that
-the following lines are in the ``main.cf`` Postgres configuration (the port
+the following lines are in the ``main.cf`` PostgreSQL configuration (the port
 may differ) to enable replication over the network:
 
 .. code-block::
@@ -650,7 +650,7 @@ may differ) to enable replication over the network:
    wal_level= logical
 
 Equally, the auditor must configure logical replication in the ``main.cf``
-Postgres configuration:
+PostgreSQL configuration:
 
 .. code-block::
 
@@ -677,7 +677,7 @@ system must subscribe:
    $ echo "CREATE PUBLICATION $NAME FOR ALL TABLES;" | psql taler-exchange
 
 
-For details, we refer to the Postgres manual.
+For details, we refer to the PostgreSQL manual.
 
 .. note::
 
@@ -686,9 +686,9 @@ For details, we refer to the Postgres manual.
    ``DROP`` operations on the tables.  Hence, the auditor cannot rely upon the
    exchange's primary copy to respect schema constraints, especially as we
    have to presume that the exchange could act maliciously.  Furthermore, it
-   is unclear to what degree Postgres database replication mechanisms are
+   is unclear to what degree PostgreSQL database replication mechanisms are
    robust against a malicious master database.  Thus, the auditor should
-   isolate its primary copy of the exchange database, including the Postgres
+   isolate its primary copy of the exchange database, including the PostgreSQL
    process, from its actual operational data.
 
 
@@ -708,7 +708,7 @@ While ``taler-auditor-sync`` could in theory be run directly against the
 exchange's production system, this is likely a bad idea due to the high
 latency from the network between auditor and exchange operator. Thus, we
 recommend first making an "untrusted" ingress copy of the exchange's
-production database using standard Postgres tooling, and then using
+production database using standard PostgreSQL tooling, and then using
 ``taler-auditor-sync`` to create a second "safe" copy.  The "safe" copy used
 by the production system should also run under a different UID.