s/Postgres/PostgreSQL/g

2 files changed, 7 insertions, 7 deletions

diff --git a/design-documents/010-exchange-helpers.rst b/design-documents/010-exchange-helpers.rst
index e67fca4e..a12b4a20 100644
--- a/design-documents/010-exchange-helpers.rst
+++ b/design-documents/010-exchange-helpers.rst
@@ -13,7 +13,7 @@ Motivation
 
 We want to provide an additional layer of protection for the private online
 signing keys used by the exchange. The exchange is network-facing, includes an
-HTTP server, Postgres interaction, JSON parser and quite a bit of other logic
+HTTP server, PostgreSQL interaction, JSON parser and quite a bit of other logic
 which may all be theoretically vulnerable to remote exploitation.  Thus, it
 would be good from a security perspective to protect the private online
 signing keys via an additional layer of protection.
@@ -89,7 +89,7 @@ Exchange design considerations:
   exchange. This simplifies the exchange, and we already needed the
   exchange operator to start four processes to operate an exchange.
   So this number simply increases to six (not even counting the
-  Postgres database and a reverse HTTP proxy for TLS termination).
+  PostgreSQL database and a reverse HTTP proxy for TLS termination).
 * Each exchange thread will create its own connection to the helpers, and will
   block while waiting on the helper to create a signature.  This keeps the
   exchange logic simple and similar to the existing in-line signing calls.
@@ -108,7 +108,7 @@ New exchange endpoints:
   sign based on that file, and then upload the resulting signature back to
   the exchange. For this, master signatures will be POSTed to
   the exchange to the ``/keys`` endpoint.
-  The exchange will keep those signatures in the Postgres database.
+  The exchange will keep those signatures in the PostgreSQL database.
 * A new endpoint (``/auditors``) will also allow adding/removing auditors
   (POST, DELETE) using requests signed with the offline master private key.
   Once an auditor has been added, the respective auditor signatures on exchange
diff --git a/design-documents/011-auditor-db-sync.rst b/design-documents/011-auditor-db-sync.rst
index f8229b63..d49503d2 100644
--- a/design-documents/011-auditor-db-sync.rst
+++ b/design-documents/011-auditor-db-sync.rst
@@ -89,9 +89,9 @@ Proposed Solution
 * The auditor's "ingress" database should be well isolated from
   the rest of the auditor's system and database
   (different user accounts). The reason is that we should not
-  assume that the Postgres replication code is battle-tested with
+  assume that the PostgreSQL replication code is battle-tested with
   malicious parties in mind.
-* The canonical Postgres synchronization between exchange and the
+* The canonical PostgreSQL synchronization between exchange and the
   auditor's "ingress" database must use transport security.
 
 The above solution does not gracefully handle mutable tables on which
@@ -148,10 +148,10 @@ A good order for replicating the tables should be:
 Alternatives
 ============
 
-* Copy the Postgres WAL, filter it for "illegal" operations
+* Copy the PostgreSQL WAL, filter it for "illegal" operations
   and then apply it at the auditor end.  Disadvantages: WAL
   filtering is not a common operation (format documented?),
-  this would be highly Postgres-specific, and would require
+  this would be highly PostgreSQL-specific, and would require
   complex work to write the filter.  Also unsure how one
   could later recover gracefully from transient errors
   (say where the exchange recified a bogus DELETE).