docs: Standardize on PostgreSQL, not Postgres.

Dockerfile-postgresql

@@ -1,7 +1,7 @@
 # To build run `docker build -f Dockerfile-postgresql .` from the root of the
 # zulip repo.
 
-# Currently the postgres images do not support automatic upgrading of
+# Currently the PostgreSQL images do not support automatic upgrading of
 # the on-disk data in volumes. So the base image can not currently be upgraded
 # without users needing a manual pgdump and restore.
 

docs/overview/architecture-overview.md

@@ -228,13 +228,13 @@ Also see [the queuing guide](../subsystems/queuing.md).
 
 ### PostgreSQL
 
-PostgreSQL (also known as Postgres) is the database that stores all
+PostgreSQL is the database that stores all persistent data, that is,
-persistent data, that is, data that's expected to live beyond a user's
+data that's expected to live beyond a user's current session.
-current session.  Starting with Zulip 3.0, new Zulip installations
+Starting with Zulip 3.0, new Zulip installations will install modern
-will install modern Postgres release rather than using the version included
+PostgreSQL release rather than using the version included with the
-with the operating system.
+operating system.
 
-In production, Postgres is installed with a default configuration. The
+In production, PostgreSQL is installed with a default configuration. The
 directory that would contain configuration files
 (`puppet/zulip/files/postgresql`) has only a utility script and a custom
 list of stopwords used by a PostgreSQL extension.

docs/overview/changelog.md

@@ -31,7 +31,7 @@ in bursts.
   data will fascilitate future features showing a log of activity by
   a given user or changes to an organization's settings.
 - Added support for using Sentry for processing backend exceptions.
-- Added documentation for using `wal-g` for continuous Postgres backups.
+- Added documentation for using `wal-g` for continuous PostgreSQL backups.
 - Added loading spinners for message editing widgets.
 - Added live update of compose placeholder text when recipients change.
 - The Zoom integration is now stable (no longer beta).
@@ -161,14 +161,14 @@ in bursts.
   duplicate accounts before upgrading.  Zulip Cloud only had two
   accounts affected by this bug, so we expect the vast majority of
   installations will have none.
-- This release switches Zulip to install Postgres 12 from the upstream
+- This release switches Zulip to install PostgreSQL 12 from the upstream
-  Postgres repository by default, rather than using the default
+  PostgreSQL repository by default, rather than using the default
-  Postgres version included with the operating system.  Existing Zulip
+  PostgreSQL version included with the operating system.  Existing Zulip
-  installations will continue to work with Postgres 10; this detail is
+  installations will continue to work with PostgreSQL 10; this detail is
   configured in `/etc/zulip/zulip.conf`.  We have no concrete plans to
-  start requiring Postgres 12, though we do expect it to improve
+  start requiring PostgreSQL 12, though we do expect it to improve
   performance.  Installations that would like to upgrade can follow
-  [our new Postgres upgrade guide][postgres-upgrade].
+  [our new PostgreSQL upgrade guide][postgresql-upgrade].
 - The format of the `JWT_AUTH_KEYS` setting has changed to include an
   [algorithms](https://pyjwt.readthedocs.io/en/latest/algorithms.html)
   list: `{"subdomain": "key"}` becomes `{"subdomain": {"key": "key",
@@ -182,7 +182,7 @@ in bursts.
   Upgrade notes for all releases one is upgrading across.
 
 [manage-shell]: ../production/management-commands.html#manage-py-shell
-[postgres-upgrade]: ../production/upgrade-or-modify.html#upgrading-postgresql
+[postgresql-upgrade]: ../production/upgrade-or-modify.html#upgrading-postgresql
 
 #### Full feature changelog
 
@@ -322,7 +322,7 @@ in bursts.
 ### 2.1.7 -- 2020-06-25
 
 - CVE-2020-15070: Fix privilege escalation vulnerability with custom
-  profile fields and direct write access to Zulip's Postgres database.
+  profile fields and direct write access to Zulip's PostgreSQL database.
 - Changed default memcached authentication username to zulip@localhost,
   fixing authentication problems when servers change their hostname.
 
@@ -366,7 +366,7 @@ details.
 
 - Fixed a regression in 2.1.3 that impacted creating the very first
   organization via our data import tools.
-- Remove the old `tsearch_extras` Postgres extension, which was causing
+- Remove the old `tsearch_extras` PostgreSQL extension, which was causing
   an exception restoring backups on fresh Zulip servers that had been
   generated on systems that had been upgraded from older Zulip releases.
 - Removed fetching GitHub contributor data from static asset build
@@ -444,7 +444,7 @@ details.
 - Added support for Debian buster.  Removed support for EOL Ubuntu Trusty.
 - Added support for SAML authentication.
 - Removed our dependency on `tsearch_extras`, making it possible to
-  run a production Zulip server against any Postgres database
+  run a production Zulip server against any PostgreSQL database
   (including those where one cannot install extensions, like Amazon RDS).
 - Significantly improved the email->Zulip gateway, and added [nice
   setup documentation](../production/email-gateway.md).  It now
@@ -700,7 +700,7 @@ lose the setting and need to re-enable it.
 - Fixed a table layout bug in "deactivated users" settings.
 - Fixed an exception when administrators edited bot users when custom
   profile fields were configured in the organization.
-- Fixed a bug enabling the PGRoonga search backend with older Postgres.
+- Fixed a bug enabling the PGRoonga search backend with older PostgreSQL.
 - Fixed getting personal API key when passwords are disabled.
 
 ### 2.0.3 -- 2019-04-23
@@ -1406,7 +1406,7 @@ running a version from before 1.7 should upgrade directly to 1.7.1.
 - Fixed the behavior of key combintions like Ctrl+Enter in the compose box.
 - Worked around Google Compute Engine's default boto configuration,
   which broke Zulip (and any other app using boto).
-- Zulip now will gracefully handle the Postgres server being restarted.
+- Zulip now will gracefully handle the PostgreSQL server being restarted.
 - Optimized marking an entire topic as read.
 - Switched from npm to yarn for downloading JS packages.
 - Switched the function of the 'q' and 'w' search hotkeys.
@@ -1717,7 +1717,7 @@ Zulip apps.
 - Added numerous hooks to Puppet modules to enable more configurations.
 - Moved several useful Puppet components into the main Puppet
   manifests (setting a Redis password, etc.).
-- Added automatic configuration of Postgres/memcached settings based
+- Added automatic configuration of PostgreSQL/memcached settings based
   on the server's available RAM.
 - Added scripts/upgrade-zulip-from-git for upgrading Zulip from a Git repo.
 - Added preliminary support for Python 3.  All of Zulip's test suites now
@@ -1834,7 +1834,7 @@ Zulip apps.
 
 ### 1.3.11 - 2016-05-02
 - Moved email digest support into the default Zulip production configuration.
-- Added options for configuring Postgres, RabbitMQ, Redis, and memcached
+- Added options for configuring PostgreSQL, RabbitMQ, Redis, and memcached
   in settings.py.
 - Added documentation on using Hubot to integrate with useful services
   not yet integrated with Zulip directly (e.g. Google Hangouts).
@@ -1864,7 +1864,7 @@ Zulip apps.
 - Added new integration for Travis CI.
 - Added settings option to control maximum file upload size.
 - Added support for running Zulip development environment in Docker.
-- Added easy configuration support for a remote Postgres database.
+- Added easy configuration support for a remote PostgreSQL database.
 - Added extensive documentation on scalability, backups, and security.
 - Recent private message threads are now displayed expanded similar to
   the pre-existing recent topics feature.

docs/production/deployment.md

@@ -50,13 +50,13 @@ specific reason to prefer Docker.
 Zulip has full support for each top-level service living on its own
 machine.
 
-You can configure remote servers for Postgres, RabbitMQ, Redis,
+You can configure remote servers for PostgreSQL, RabbitMQ, Redis,
 in `/etc/zulip/settings.py`; just search for the service name in that
 file and you'll find inline documentation in comments for how to
 configure it.
 
 Since some of these services require some configuration on the node
-itself (e.g. installing our Postgres extensions), we have designed
+itself (e.g. installing our PostgreSQL extensions), we have designed
 the Puppet configuration that Zulip uses for installing and upgrading
 configuration to be completely modular.
 
@@ -103,9 +103,9 @@ sudo -s  # If not already root
     --no-init-db --postgres-missing-dictionaries
 ```
 
-The script also installs and starts Postgres on the server by
+The script also installs and starts PostgreSQL on the server by
 default. We don't need it, so run the following command to
-stop and disable the local Postgres server.
+stop and disable the local PostgreSQL server.
 
 ```
 sudo service postgresql stop
@@ -114,9 +114,9 @@ sudo update-rc.d postgresql disable
 
 This complication will be removed in a future version.
 
-#### Step 2: Create the Postgres database
+#### Step 2: Create the PostgreSQL database
 
-Access an administrative `psql` shell on your Postgres database, and
+Access an administrative `psql` shell on your PostgreSQL database, and
 run the commands in `scripts/setup/create-db.sql` to:
 
 * Create a database called `zulip`.
@@ -125,19 +125,19 @@ run the commands in `scripts/setup/create-db.sql` to:
   `zulip` in the `zulip` database. You might have to grant `create`
   privileges first for the `zulip` user to do this.
 
-Depending on how authentication works for your Postgres installation,
+Depending on how authentication works for your PostgreSQL installation,
 you may also need to set a password for the Zulip user, generate a
 client certificate, or similar; consult the documentation for your
 database provider for the available options.
 
-#### Step 3: Configure Zulip to use the Postgres database
+#### Step 3: Configure Zulip to use the PostgreSQL database
 
 In `/etc/zulip/settings.py` on your Zulip server, configure the
-following settings with details for how to connect to your Postgres
+following settings with details for how to connect to your PostgreSQL
 server.  Your database provider should provide these details.
 
-* `REMOTE_POSTGRES_HOST`: Name or IP address of the Postgres server.
+* `REMOTE_POSTGRES_HOST`: Name or IP address of the PostgreSQL server.
-* `REMOTE_POSTGRES_PORT`: Port on the Postgres server.
+* `REMOTE_POSTGRES_PORT`: Port on the PostgreSQL server.
 * `REMOTE_POSTGRES_SSLMODE`: SSL Mode used to connect to the server.
 
 If you're using password authentication, you should specify the
@@ -151,7 +151,7 @@ postgres_password = abcd1234
 Now complete the installation by running the following commands.
 
 ```
-# Ask Zulip installer to initialize the Postgres database.
+# Ask Zulip installer to initialize the PostgreSQL database.
 su zulip -c '/home/zulip/deployments/current/scripts/setup/initialize-database'
 
 # And then generate a realm creation link:
@@ -513,7 +513,7 @@ setting](https://www.postgresql.org/docs/current/runtime-config-query.html#GUC-R
 
 Set to non-empty to enable replication to enable [streaming
 replication between PostgreSQL
-servers](../production/export-and-import.html#postgres-streaming-replication).
+servers](../production/export-and-import.html#postgresql-streaming-replication).
 
 #### `ssl_ca_file`
 

docs/production/expensive-migrations.md

@@ -16,8 +16,8 @@ can run them manually before starting the upgrade:
   then run `su zulip` to drop privileges), and `cd
   /home/zulip/deployments/current`
 2. Run `./manage.py dbshell`.  This will open a shell connected to the
-  Postgres database.
+  PostgreSQL database.
-3. In the Postgres shell, run the following commands:
+3. In the PostgreSQL shell, run the following commands:
 
         CREATE INDEX CONCURRENTLY
         zerver_usermessage_is_private_message_id

docs/production/export-and-import.md

@@ -12,7 +12,7 @@ service (or back):
   * Backups must be restored on a server running the same Zulip
     version (most precisely, one where `manage.py showmigrations` has
     the same output).
-  * Backups must be restored on a server running the same Postgres
+  * Backups must be restored on a server running the same PostgreSQL
     version.
   * Backups aren't useful for migrating organizations between
     self-hosting and Zulip Cloud (which may require renumbering all
@@ -20,7 +20,7 @@ service (or back):
 
   We highly recommend this tool in situations where it is applicable,
   because it is highly optimized and highly stable, since the hard
-  work is done by the built-in backup feature of Postgres.  We also
+  work is done by the built-in backup feature of PostgreSQL.  We also
   document [backup details](#backup-details) for users managing
   backups manually.
 
@@ -36,7 +36,7 @@ service (or back):
   Like the backup tool, logical data exports must be imported on a
   Zulip server running the same version.  However, logical data
   exports can be imported on Zulip servers running a different
-  Postgres version or hosting a different set of Zulip
+  PostgreSQL version or hosting a different set of Zulip
   organizations.  We recommend this tool in cases where the backup
   tool isn't applicable, including situations where an easily
   machine-parsable export format is desired.
@@ -47,8 +47,8 @@ service (or back):
   inexpensively preserve public stream conversations when
   decommissioning a Zulip organization.
 
-* It's possible to set up [Postgres streaming
+* It's possible to set up [PostgreSQL streaming
-  replication](#postgres-streaming-replication) and the [S3 file
+  replication](#postgresql-streaming-replication) and the [S3 file
   upload
   backend](../production/upload-backends.html#s3-backend-configuration)
   as part of a high evailability environment.
@@ -69,7 +69,7 @@ The backup tool provides the following options:
   to (default: write to a file in `/tmp`).  On success, the
   console output will show the path to the output tarball.
 - `--skip-db`: Skip backup of the database.  Useful if you're using a
-  remote Postgres host with its own backup system and just need to
+  remote PostgreSQL host with its own backup system and just need to
   backup non-database state.
 - `--skip-uploads`: If `LOCAL_UPLOADS_DIR` is set, user-uploaded files
   in that directory will be ignored.
@@ -228,9 +228,9 @@ confirm that your backups are working. You may also want to monitor
 that they are up to date using the Nagios plugin at:
 `puppet/zulip/files/nagios_plugins/zulip_postgresql_backups/check_postgresql_backup`.
 
-## Postgres streaming replication
+## PostgreSQL streaming replication
 
-Zulip has database configuration for using Postgres streaming
+Zulip has database configuration for using PostgreSQL streaming
 replication. You can see the configuration in these files:
 
 * `puppet/zulip_ops/manifests/profile/postgresql.pp`

docs/production/install.md

@@ -131,7 +131,7 @@ directory there, and makes `/home/zulip/deployments/current` as a
 symbolic link to it.
 * Installs Zulip's various dependencies.
 * Configures the various third-party services Zulip uses, including
-Postgres, RabbitMQ, Memcached and Redis.
+PostgreSQL, RabbitMQ, Memcached and Redis.
 * Initializes Zulip's database.
 
 If you'd like to deploy Zulip with these services on different

docs/production/management-commands.md

@@ -106,9 +106,9 @@ There are dozens of useful management commands under
 
 * `./manage.py help`: Lists all available management commands.
 * `./manage.py dbshell`: If you're more comfortable with raw SQL than
-  Python, this will open a Postgres SQL shell connected to the Zulip
+  Python, this will open a PostgreSQL SQL shell connected to the Zulip
   server's database.  Beware of changing data; editing data directly
-  with SQL will often not behave correctly because Postgres doesn't
+  with SQL will often not behave correctly because PostgreSQL doesn't
   know to flush Zulip's caches or notify browsers of changes.
 * `./manage.py send_custom_email`: Can be used to send an email to a set
   of users.  The `--help` documents how to run it from a `manage.py

docs/production/postgres.md

@@ -1,23 +1,23 @@
-Postgres database details
+PostgreSQL database details
 =========================
 
-Starting with Zulip 3.0, Zulip supports using Postgres 10, 11, or 12,
+Starting with Zulip 3.0, Zulip supports using PostgreSQL 10, 11, or 12,
-defaulting to Postgres 12 for new installations.
+defaulting to PostgreSQL 12 for new installations.
 
-Previous versions of Zulip used whatever version of Postgres was
+Previous versions of Zulip used whatever version of PostgreSQL was
-included with the base operating system (E.g. Postgres 12 on Ubuntu
+included with the base operating system (E.g. PostgreSQL 12 on Ubuntu
 Focal, 10 on Ubuntu Bionic, and 9.6 on Ubuntu Xenial).  We recommend
-that installations currently using older Postgres releases [upgrade to
+that installations currently using older PostgreSQL releases [upgrade to
-Postgres 12][upgrade-postgres], as may drop support for older Postgres
+PostgreSQL 12][upgrade-postgres], as may drop support for older PostgreSQL
 in a future release.
 
 [upgrade-postgres]: ../production/upgrade-or-modify.html#upgrading-postgresql
 
-#### Remote Postgres database
+#### Remote PostgreSQL database
 
 This is a bit annoying to set up, but you can configure Zulip to use a
-dedicated Postgres server by setting the `REMOTE_POSTGRES_HOST`
+dedicated PostgreSQL server by setting the `REMOTE_POSTGRES_HOST`
-variable in /etc/zulip/settings.py, and configuring Postgres
+variable in /etc/zulip/settings.py, and configuring PostgreSQL
 certificate authentication (see
 http://www.postgresql.org/docs/9.1/static/ssl-tcp.html and
 http://www.postgresql.org/docs/9.1/static/libpq-ssl.html for
@@ -64,15 +64,15 @@ sudo update-rc.d postgresql disable
 ```
 
 In future versions of this feature, we'd like to implement and
-document how to the remote Postgres database server itself
+document how to the remote PostgreSQL database server itself
 automatically by using the Zulip install script with a different set
 of Puppet manifests than the all-in-one feature; if you're interested
 in working on this, post to the Zulip development mailing list and we
 can give you some tips.
 
-#### Debugging Postgres database issues
+#### Debugging PostgreSQL database issues
 
-When debugging Postgres issues, in addition to the standard `pg_top`
+When debugging PostgreSQL issues, in addition to the standard `pg_top`
 tool, often it can be useful to use this query:
 
 ```
@@ -88,13 +88,13 @@ int)` or `SELECT pg_terminate_backend(pid int)` as the 'postgres'
 user. The former cancels the backend's current query and the latter
 terminates the backend process. They are implemented by sending SIGINT
 and SIGTERM to the processes, respectively.  We recommend against
-sending a Postgres process SIGKILL. Doing so will cause the database
+sending a PostgreSQL process SIGKILL. Doing so will cause the database
 to kill all current connections, roll back any pending transactions,
 and enter recovery mode.
 
-#### Stopping the Zulip Postgres database
+#### Stopping the Zulip PostgreSQL database
 
-To start or stop Postgres manually, use the pg_ctlcluster command:
+To start or stop PostgreSQL manually, use the pg_ctlcluster command:
 
 ```
 pg_ctlcluster 9.1 [--force] main {start|stop|restart|reload}
@@ -120,12 +120,12 @@ Many database parameters can be adjusted while the database is
 running. Just modify /etc/postgresql/9.1/main/postgresql.conf and
 issue a reload. The logs will note the change.
 
-#### Debugging issues starting Postgres
+#### Debugging issues starting PostgreSQL
 
 pg_ctlcluster often doesn't give you any information on why the
 database failed to start. It may tell you to check the logs, but you
 won't find any information there. pg_ctlcluster runs the following
-command underneath when it actually goes to start Postgres:
+command underneath when it actually goes to start PostgreSQL:
 
 ```
 /usr/lib/postgresql/9.1/bin/pg_ctl start -D /var/lib/postgresql/9.1/main -s -o \
@@ -134,18 +134,18 @@ command underneath when it actually goes to start Postgres:
 
 Since pg_ctl doesn't redirect stdout or stderr, running the above can
 give you better diagnostic information. However, you might want to
-stop Postgres and restart it using pg_ctlcluster after you've debugged
+stop PostgreSQL and restart it using pg_ctlcluster after you've debugged
 with this approach, since it does bypass some of the work that
 pg_ctlcluster does.
 
 
-#### Postgres vacuuming alerts
+#### PostgreSQL vacuuming alerts
 
-The `autovac_freeze` Postgres alert from `check_postgres` is
+The `autovac_freeze` PostgreSQL alert from `check_postgres` is
 particularly important.  This alert indicates that the age (in terms
 of number of transactions) of the oldest transaction id (XID) is
 getting close to the `autovacuum_freeze_max_age` setting.  When the
-oldest XID hits that age, Postgres will force a VACUUM operation,
+oldest XID hits that age, PostgreSQL will force a VACUUM operation,
 which can often lead to sudden downtime until the operation finishes.
 If it did not do this and the age of the oldest XID reached 2 billion,
 transaction id wraparound would occur and there would be data loss.
@@ -154,4 +154,4 @@ database as a database superuser (`postgres`).
 
 See
 http://www.postgresql.org/docs/9.1/static/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND
-for more details on Postgres vacuuming.
+for more details on PostgreSQL vacuuming.

docs/production/requirements.md

@@ -149,7 +149,7 @@ most use cases, there's little scalability benefit to doing so.  See
 installing Zulip with a dedicated database server.
 
 * **Dedicated database**.  For installations with hundreds of daily
-  active users, we recommend using a [remote Postgres
+  active users, we recommend using a [remote PostgreSQL
   database](postgres.md), but it's not required.
 
 * **RAM:**  We recommended more RAM for larger installations:
@@ -191,7 +191,7 @@ installing Zulip with a dedicated database server.
   always idle), and its database was using about 100GB of disk.
 
 * **Disaster recovery:** One can easily run a hot spare application
-  server and a hot spare database (using [Postgres streaming
+  server and a hot spare database (using [PostgreSQL streaming
   replication][streaming-replication]).  Make sure the hot spare
   application server has copies of `/etc/zulip` and you're either
   syncing `LOCAL_UPLOADS_DIR` or using the [S3 file uploads
@@ -214,5 +214,5 @@ whether Zulip is a fit for your organization or need further advice
 [contact Zulip support][contact-support].
 
 [s3-uploads]: ../production/upload-backends.html#s3-backend-configuration
-[streaming-replication]: ../production/export-and-import.html#postgres-streaming-replication
+[streaming-replication]: ../production/export-and-import.html#postgresql-streaming-replication
 [contact-support]: https://zulip.com/help/contact-support

docs/production/troubleshooting.md

@@ -141,11 +141,11 @@ problems and how to resolve them:
     <https://linoxide.com/ubuntu-how-to/enable-disable-unattended-upgrades-ubuntu-16-04/>`;
     if you disable them, do not forget to regularly install apt upgrades
     manually.  With unattended upgrades enabled but not limited, the
-    moment a new Postgres release is published, your Zulip server will
+    moment a new PostgreSQL release is published, your Zulip server will
-    have its Postgres server upgraded (and thus restarted).
+    have its PostgreSQL server upgraded (and thus restarted).
 ```
 
-Restarting one of the system services that Zulip uses (Postgres,
+Restarting one of the system services that Zulip uses (PostgreSQL,
 memcached, Redis, or Rabbitmq) will drop the connections that
 Zulip processes have to the service, resulting in future operations on
 those connections throwing errors.
@@ -167,7 +167,7 @@ workers are commonly idle for periods of hours or days at a time.
 You can prevent this trickle when doing a planned upgrade by
 restarting the Zulip server with
 `/home/zulip/deployments/current/scripts/restart-server` after
-installing system package updates to Postgres, memcached,
+installing system package updates to PostgreSQL, memcached,
 RabbitMQ, or Redis.
 
 You can ensure that the `unattended-upgrades` package never upgrades
@@ -204,7 +204,7 @@ standard stuff:
   especially for the database and where uploads are stored.
 * Service uptime and standard monitoring for the [services Zulip
   depends on](#troubleshooting-services).  Most monitoring software
-  has standard plugins for Nginx, Postgres, Redis, RabbitMQ,
+  has standard plugins for Nginx, PostgreSQL, Redis, RabbitMQ,
   and memcached, and those will work well with Zulip.
 * `supervisorctl status` showing all services `RUNNING`.
 * Checking for processes being OOM killed.
@@ -245,8 +245,8 @@ Database monitoring:
 * `check_fts_update_log`: Checks whether full-text search updates are
   being processed properly or getting backlogged.
 * `check_postgres`: General checks for database health.
-* `check_postgresql_backup`: Checks status of Postgres backups.
+* `check_postgresql_backup`: Checks status of PostgreSQL backups.
-* `check_postgresql_replication_lag`: Checks whether Postgres streaming
+* `check_postgresql_replication_lag`: Checks whether PostgreSQL streaming
   replication is up to date.
 
 Standard server monitoring:

docs/production/upgrade-or-modify.md

@@ -195,7 +195,7 @@ some additional steps to update your Zulip installation, documented
 below.
 
 The steps are largely the same for the various OS upgrades aside from
-the versions of Postgres, so you should be able to adapt these
+the versions of PostgreSQL, so you should be able to adapt these
 instructions for other supported platforms.
 
 ### Upgrading from Ubuntu 18.04 Bionic to 20.04 Focal
@@ -226,7 +226,7 @@ instructions for other supported platforms.
     release update of Ubuntu 20.04 LTS is released.
 
     When `do-release-upgrade` asks you how to upgrade configuration
-    files for services that Zulip manages like Redis, Postgres,
+    files for services that Zulip manages like Redis, PostgreSQL,
     Nginx, and memcached, the best choice is `N` to keep the
     currently installed version.  But it's not important; the next
     step will re-install Zulip's configuration in any case.
@@ -357,7 +357,7 @@ instructions for other supported platforms.
    [debian-upgrade-os]: https://www.debian.org/releases/buster/amd64/release-notes/ch-upgrading.html
 
    When prompted for you how to upgrade configuration
-   files for services that Zulip manages like Redis, Postgres,
+   files for services that Zulip manages like Redis, PostgreSQL,
    Nginx, and memcached, the best choice is `N` to keep the
    currently installed version.  But it's not important; the next
    step will re-install Zulip's configuration in any case.

docs/subsystems/analytics.md

@@ -10,7 +10,7 @@ designed around the following goals:
 - Efficient to query so that we can display data in-app (e.g. on the streams
   page) with minimum impact on the overall performance of those pages.
 - Storage size smaller than the size of the main Message/UserMessage
-  database tables, so that we can store the data in the main Postgres
+  database tables, so that we can store the data in the main PostgreSQL
   database rather than using a specialized database platform.
 
 There are a few important things you need to understand in order to
@@ -89,7 +89,7 @@ it's easy to end up processing a huge amount of data inefficiently and
 needing a system like Hadoop to manage it. For the built-in analytics in
 Zulip, we've designed something lightweight and fast that can be available
 on any Zulip server without any extra dependencies through the carefully
-designed set of tables in Postgres.
+designed set of tables in PostgreSQL.
 
 This requires some care to avoid making the analytics tables larger than the
 rest of the Zulip database or adding a ton of computational load, but with

docs/subsystems/dependencies.md

@@ -90,7 +90,7 @@ the backend, but does in JavaScript.
 
 ## System packages
 
-For the third-party services like Postgres, Redis, Nginx, and RabbitMQ
+For the third-party services like PostgreSQL, Redis, Nginx, and RabbitMQ
 that are documented in the
 [architecture overview](../overview/architecture-overview.md), we rely on the
 versions of those packages provided alongside the Linux distribution
@@ -113,7 +113,7 @@ few places:
   install other dependencies, and (2) because that list is shared
   between development and production.
 
-We also rely on the PGroonga PPA for the PGroonga Postgres
+We also rely on the PGroonga PPA for the PGroonga PostgreSQL
 extension, used by our [full-text search](full-text-search.md).
 
 ## Python packages

docs/subsystems/schema-migrations.md

@@ -48,7 +48,7 @@ migrations.
   to the table, performing data backfills, or building indexes. We
   have a `zerver/lib/migrate.py` library to help with adding columns
   and backfilling data.  For building indexes on these tables, we
-  should do this using SQL with Postgres's CONCURRENTLY keyword.
+  should do this using SQL with PostgreSQL's CONCURRENTLY keyword.
 
 * **Atomicity**.  By default, each Django migration is run atomically
   inside a transaction.  This can be problematic if one wants to do

docs/subsystems/settings.md

@@ -53,7 +53,7 @@ In a production environment, we have:
   `zproject/prod_settings_template.py`) is the main system
   administrator-facing settings file for Zulip.  It contains all the
   server-specific settings, such as how to send outgoing email, the
-  hostname of the Postgres database, etc., but does not contain any
+  hostname of the PostgreSQL database, etc., but does not contain any
   secrets (e.g. passwords, secret API keys, cryptographic keys, etc.).
   The way we generally do settings that can be controlled with shell
   access to a Zulip server is to put a default in

docs/testing/philosophy.md

@@ -66,7 +66,7 @@ these goals, but a few techniques are worth highlighting:
   outgoing HTTP requests are required to test something, we mock the
   responses with libraries like `responses`.
 * We carefully avoid the potential for contamination of data inside
-  services like Postgres, Redis, and memcached from different tests.
+  services like PostgreSQL, Redis, and memcached from different tests.
     * Every test case prepends a unique random prefix to all keys it
       uses when accessing Redis and memcached.
     * Every test case runs inside a database transaction, which is

puppet/zulip/files/nagios_plugins/zulip_postgresql/check_postgresql_replication_lag

@@ -1,8 +1,8 @@
 #!/usr/bin/env python3
 
 """Nagios plugin to check the difference between the primary and
-replica Postgres servers' xlog location.  Requires that the user this
+replica PostgreSQL servers' xlog location.  Requires that the user this
-connects to Postgres as has been granted the `pg_monitor` role.
+connects to PostgreSQL as has been granted the `pg_monitor` role.
 
 """
 import re

puppet/zulip/files/nagios_plugins/zulip_postgresql_backups/check_postgresql_backup

@@ -25,9 +25,9 @@ try:
     with open('/var/lib/nagios_state/last_postgresql_backup') as f:
         last_backup = dateutil.parser.parse(f.read())
 except OSError:
-    report('UNKNOWN', 'could not determine completion time of last Postgres backup')
+    report('UNKNOWN', 'could not determine completion time of last PostgreSQL backup')
 
 if datetime.now(tz=timezone.utc) - last_backup > timedelta(hours=25):
-    report('CRITICAL', f'last Postgres backup completed more than 25 hours ago: {last_backup}')
+    report('CRITICAL', f'last PostgreSQL backup completed more than 25 hours ago: {last_backup}')
 
-report('OK', f'last Postgres backup completed less than 25 hours ago: {last_backup}')
+report('OK', f'last PostgreSQL backup completed less than 25 hours ago: {last_backup}')

puppet/zulip/files/postgresql/pg_backup_and_purge

@@ -35,7 +35,7 @@ if is_rhel_based:
 else:
     pg_data_paths = glob.glob('/var/lib/postgresql/*/main')
 if len(pg_data_paths) != 1:
-    print(f"Postgres installation is not unique: {pg_data_paths}")
+    print(f"PostgreSQL installation is not unique: {pg_data_paths}")
     sys.exit(1)
 pg_data_path = pg_data_paths[0]
 run(['env-wal-g', 'backup-push', pg_data_path])

puppet/zulip/files/postgresql/process_fts_updates

@@ -1,10 +1,10 @@
 #!/usr/bin/env python3
-# Processes updates to Postgres full-text search for new/edited messages.
+# Processes updates to PostgreSQL full-text search for new/edited messages.
 #
-# Zulip manages its Postgres full-text search as follows.  When the
+# Zulip manages its PostgreSQL full-text search as follows.  When the
-# content of a message is modified, a Postgres trigger logs the
+# content of a message is modified, a PostgreSQL trigger logs the
 # message ID to the `fts_update_log` table.  In the background, this
-# program processes `fts_update_log`, updating the Postgres full-text
+# program processes `fts_update_log`, updating the PostgreSQL full-text
 # search column search_tsvector in the main zerver_message.
 import sys
 
@@ -88,7 +88,7 @@ try:
     USING_PGROONGA = settings.USING_PGROONGA
 except ImportError:
     # process_fts_updates also supports running locally on a remote
-    # Postgres server; in that case, one can just connect to localhost
+    # PostgreSQL server; in that case, one can just connect to localhost
     USING_PGROONGA = False
 
 # Since we don't want a hard dependency on being able to access the

puppet/zulip/manifests/postgresql_base.pp

@@ -33,7 +33,7 @@ class zulip::postgresql_base {
       $pgroonga_setup_sql_path = "${postgresql_sharedir}/pgroonga_setup.sql"
       $setup_system_deps = 'setup_yum_repo'
       $postgresql_restart = "systemctl restart postgresql-${zulip::postgresql_common::version}"
-      # TODO Since we can't find the Postgres dicts directory on CentOS yet, we
+      # TODO Since we can't find the PostgreSQL dicts directory on CentOS yet, we
       # link directly to the hunspell directory.
       $postgresql_dict_dict = '/usr/share/myspell/en_US.dic'
       $postgresql_dict_affix = '/usr/share/myspell/en_US.aff'

puppet/zulip/manifests/postgresql_common.pp

@@ -12,7 +12,7 @@ class zulip::postgresql_common {
         'ssl-cert',
         # our dictionary
         'hunspell-en-us',
-        # Postgres Nagios check plugin
+        # PostgreSQL Nagios check plugin
         'check-postgres',
         # Python modules used in our monitoring/worker threads
         'python3-dateutil', # TODO: use a virtualenv instead

puppet/zulip_ops/files/nagios3/conf.d/services.cfg

@@ -156,7 +156,7 @@ define service {
 
 define service {
         use                             generic-service
-        service_description             Check Postgres autovac_freeze
+        service_description             Check PostgreSQL autovac_freeze
         check_command                   check_postgres!zulip!nagios!autovac_freeze
         hostgroup                       postgresql_primary
         contact_groups                  admins
@@ -164,7 +164,7 @@ define service {
 
 define service {
         use                             generic-service
-        service_description             Check Postgres backends
+        service_description             Check PostgreSQL backends
         check_command                   check_postgres!zulip!nagios!backends
         hostgroup                       postgresql
         contact_groups                  admins
@@ -172,7 +172,7 @@ define service {
 
 define service {
         use                             generic-service
-        service_description             Check Postgres connection
+        service_description             Check PostgreSQL connection
         check_command                   check_postgres!zulip!nagios!connection
         hostgroup                       postgresql
         contact_groups                  page_admins
@@ -180,7 +180,7 @@ define service {
 
 define service {
         use                             generic-service
-        service_description             Check Postgres disabled triggers
+        service_description             Check PostgreSQL disabled triggers
         check_command                   check_postgres!zulip!nagios!disabled_triggers
         hostgroup                       postgresql
         contact_groups                  admins
@@ -188,7 +188,7 @@ define service {
 
 define service {
         use                             generic-service
-        service_description             Check Postgres hitratio
+        service_description             Check PostgreSQL hitratio
         check_command                   check_postgres!zulip!nagios!hitratio
         hostgroup                       postgresql
         contact_groups                  admins
@@ -196,7 +196,7 @@ define service {
 
 define service {
         use                             generic-service
-        service_description             Check Postgres locks
+        service_description             Check PostgreSQL locks
         check_command                   check_postgres_alert_args!zulip!nagios!locks!400!600
         hostgroup                       postgresql
         contact_groups                  admins
@@ -204,7 +204,7 @@ define service {
 
 define service {
         use                             generic-service
-        service_description             Check Postgres query_time
+        service_description             Check PostgreSQL query_time
         check_command                   check_postgres_alert_args!zulip!nagios!query_time!20 seconds!40 seconds
         hostgroup                       postgresql
         contact_groups                  admins
@@ -212,7 +212,7 @@ define service {
 
 define service {
         use                             generic-service
-        service_description             Check Postgres sequence
+        service_description             Check PostgreSQL sequence
         check_command                   check_postgres!zulip!nagios!sequence
         hostgroup                       postgresql
         contact_groups                  admins
@@ -220,7 +220,7 @@ define service {
 
 define service {
         use                             generic-service
-        service_description             Check Postgres timesync
+        service_description             Check PostgreSQL timesync
         check_command                   check_postgres!zulip!nagios!timesync
         hostgroup                       postgresql
         contact_groups                  admins
@@ -228,7 +228,7 @@ define service {
 
 # define service {
 #         use                             generic-service
-#         service_description             Check Postgres txn_idle
+#         service_description             Check PostgreSQL txn_idle
 #         check_command                   check_postgres_alert_args!zulip!nagios!txn_idle!20 seconds!40 seconds
 #         hostgroup                       postgresql
 #         contact_groups                  admins
@@ -236,7 +236,7 @@ define service {
 
 define service {
         use                             generic-service
-        service_description             Check Postgres txn_time
+        service_description             Check PostgreSQL txn_time
         check_command                   check_postgres_alert_args!zulip!nagios!txn_time!20 seconds!40 seconds
         hostgroup                       postgresql
         contact_groups                  admins
@@ -252,7 +252,7 @@ define service {
 
 define service{
         use                             generic-service
-        service_description             Check Postgres replication lag
+        service_description             Check PostgreSQL replication lag
         check_command                   check_postgresql_replication_lag
         hostgroup                       postgresql
         contact_groups                  admins
@@ -260,7 +260,7 @@ define service{
 
 define service {
         use                             generic-service
-        service_description             Check last Postgres backup time
+        service_description             Check last PostgreSQL backup time
         check_command                   check_postgresql_backup
         hostgroup                       postgresql
         contact_groups                  admins

scripts/lib/install

@@ -29,7 +29,7 @@ Options:
       environment to produce an image which is used elsewhere.  Uncommon.
 
   --postgres-version=12
-      Sets the version of Postgres that will be installed.
+      Sets the version of PostgreSQL that will be installed.
   --postgres-missing-dictionaries
       Set postgresql.missing_dictionaries, which alters the initial database.  Use with
       cloud managed databases like RDS.  Conflicts with --no-overwrite-settings.
@@ -235,8 +235,8 @@ fi
 case ",$PUPPET_CLASSES," in
     *,zulip::profile::standalone,* | *,zulip::profile::postgresql,*)
         if [ "$package_system" = apt ]; then
-            # We're going to install Postgres from the Postgres apt
+            # We're going to install PostgreSQL from the PostgreSQL apt
-            # repository; this may conflict with the existing Postgres.
+            # repository; this may conflict with the existing PostgreSQL.
             OTHER_PG="$(dpkg --get-selections \
                 | grep -E '^postgresql-[0-9]+\s+install$' \
                 | grep -v "^postgresql-$POSTGRES_VERSION\b" \
@@ -406,7 +406,7 @@ EOF
         --classfile=/var/lib/puppet/classes.txt \
         >/dev/null
 
-    # We only need the Postgres version setting on database hosts; but
+    # We only need the PostgreSQL version setting on database hosts; but
     # we don't know if this is a database host until we have the catalog summary.
     if ! has_class "zulip::postgresql_common" || [ "$package_system" != apt ]; then
         crudini --del /etc/zulip/zulip.conf postgresql
@@ -526,7 +526,7 @@ if [ -n "$NO_INIT_DB" ]; then
  Success!
 
  Stopping because --no-init-db was passed.
- To complete the installation, configure Postgres and then run:
+ To complete the installation, configure PostgreSQL and then run:
 
    su zulip -c '/home/zulip/deployments/current/scripts/setup/initialize-database'
    su zulip -c '/home/zulip/deployments/current/manage.py generate_realm_creation_link'

scripts/setup/generate_secrets.py

@@ -88,7 +88,7 @@ def generate_secrets(development: bool = False) -> None:
             add_secret(name, random_token())
 
     # These secrets are exclusive to a Zulip development environment.
-    # We use postgres peer authentication by default in production,
+    # We use PostgreSQL peer authentication by default in production,
     # and initial_password_salt is used to generate passwords for the
     # test/development database users.  See `manage.py
     # print_initial_password`.

scripts/setup/upgrade-postgres

@@ -67,7 +67,7 @@ else
     echo "      be parsed out!  Please read the pg_upgradecluster output to understand"
     echo "      the current status of your cluster:"
     echo "          $UPGRADE_LOG"
-    echo "      and report this bug with the Postgres $UPGRADE_FROM -> $UPGRADE_TO upgrade to:"
+    echo "      and report this bug with the PostgreSQL $UPGRADE_FROM -> $UPGRADE_TO upgrade to:"
     echo "          https://github.com/zulip/zulip/issues"
     echo
     echo

tools/lib/provision.py

@@ -279,13 +279,13 @@ def install_yum_deps(deps_to_install: List[str]) -> None:
         run_as_root(["ln", "-nsf", "/usr/bin/python36", "/usr/bin/python3"])
     postgres_dir = f'pgsql-{POSTGRES_VERSION}'
     for cmd in ['pg_config', 'pg_isready', 'psql']:
-        # Our tooling expects these Postgres scripts to be at
+        # Our tooling expects these PostgreSQL scripts to be at
         # well-known paths.  There's an argument for eventually
         # making our tooling auto-detect, but this is simpler.
         run_as_root(["ln", "-nsf", f"/usr/{postgres_dir}/bin/{cmd}",
                      f"/usr/bin/{cmd}"])
 
-    # From here, we do the first-time setup/initialization for the Postgres database.
+    # From here, we do the first-time setup/initialization for the PostgreSQL database.
     pg_datadir = f"/var/lib/pgsql/{POSTGRES_VERSION}/data"
     pg_hba_conf = os.path.join(pg_datadir, "pg_hba.conf")
 
@@ -300,7 +300,7 @@ def install_yum_deps(deps_to_install: List[str]) -> None:
                 sudo_args = ['-H'])
     # Use vendored pg_hba.conf, which enables password authentication.
     run_as_root(["cp", "-a", "puppet/zulip/files/postgresql/centos_pg_hba.conf", pg_hba_conf])
-    # Later steps will ensure Postgres is started
+    # Later steps will ensure PostgreSQL is started
 
     # Link in tsearch data files
     overwrite_symlink(

tools/setup/dev-vagrant-docker/Dockerfile

@@ -28,7 +28,7 @@ ARG VAGRANT_UID
 
 RUN \
     # We use https://github.com/gdraheim/docker-systemctl-replacement
-    # to make services we install like Postgres, Redis, etc. normally
+    # to make services we install like PostgreSQL, Redis, etc. normally
     # managed by systemd start within Docker, which breaks normal
     # operation of systemd.
     dpkg-divert --add --rename /bin/systemctl \

zerver/lib/alert_words.py

@@ -69,7 +69,7 @@ def add_user_alert_words(user_profile: UserProfile, new_words: Iterable[str]) ->
 @transaction.atomic
 def remove_user_alert_words(user_profile: UserProfile, delete_words: Iterable[str]) -> List[str]:
     # TODO: Ideally, this would be a bulk query, but Django doesn't have a `__iexact`.
-    # We can clean this up if/when Postgres has more native support for case-insensitive fields.
+    # We can clean this up if/when PostgreSQL has more native support for case-insensitive fields.
     # If we turn this into a bulk operation, we will need to call flush_realm_alert_words() here.
     for delete_word in delete_words:
         AlertWord.objects.filter(user_profile=user_profile, word__iexact=delete_word).delete()

zerver/lib/migrate.py

@@ -13,7 +13,7 @@ def do_batch_update(cursor: CursorObj,
                     batch_size: int=10000,
                     sleep: float=0.1) -> None:  # nocoverage
     # The string substitution below is complicated by our need to
-    # support multiple Postgres versions.
+    # support multiple PostgreSQL versions.
     stmt = SQL('''
         UPDATE {}
         SET {}

zerver/management/commands/create_large_indexes.py

@@ -7,7 +7,7 @@ from zerver.lib.management import ZulipBaseCommand
 
 def create_indexes() -> None:
     #  Creating concurrent indexes is kind of a pain with current versions
-    #  of Django/Postgres, because you will get this error with seemingly
+    #  of Django/PostgreSQL, because you will get this error with seemingly
     #  reasonable code:
     #
     #    CREATE INDEX CONCURRENTLY cannot be executed from a function or multi-command string

zerver/views/message_fetch.py

@@ -227,15 +227,15 @@ class NarrowBuilder:
         """
         Escape user input to place in a regex
 
-        Python's re.escape escapes Unicode characters in a way which Postgres
+        Python's re.escape escapes Unicode characters in a way which PostgreSQL
         fails on, '\u03bb' to '\\\u03bb'. This function will correctly escape
-        them for Postgres, '\u03bb' to '\\u03bb'.
+        them for PostgreSQL, '\u03bb' to '\\u03bb'.
         """
         s = list(pattern)
         for i, c in enumerate(s):
             if c not in self._alphanum:
                 if ord(c) >= 128:
-                    # convert the character to hex Postgres regex will take
+                    # convert the character to hex PostgreSQL regex will take
                     # \uXXXX
                     s[i] = f'\\u{ord(c):0>4x}'
                 else:
@@ -325,7 +325,7 @@ class NarrowBuilder:
                     topic_match_sa('(instance "").d.d.d.d'),
                 )
             else:
-                # We limit `.d` counts, since Postgres has much better
+                # We limit `.d` counts, since PostgreSQL has much better
                 # query planning for this than they do for a regular
                 # expression (which would sometimes table scan).
                 cond = or_(
@@ -481,7 +481,7 @@ class NarrowBuilder:
         query = query.column(ts_locs_array(literal("zulip.english_us_search"),
                                            column("rendered_content"),
                                            tsquery).label("content_matches"))
-        # We HTML-escape the topic in Postgres to avoid doing a server round-trip
+        # We HTML-escape the topic in PostgreSQL to avoid doing a server round-trip
         query = query.column(ts_locs_array(literal("zulip.english_us_search"),
                                            func.escape_html(topic_column_sa()),
                                            tsquery).label("topic_matches"))
@@ -489,7 +489,7 @@ class NarrowBuilder:
         # Do quoted string matching.  We really want phrase
         # search here so we can ignore punctuation and do
         # stemming, but there isn't a standard phrase search
-        # mechanism in Postgres
+        # mechanism in PostgreSQL
         for term in re.findall(r'"[^"]+"|\S+', operand):
             if term[0] == '"' and term[-1] == '"':
                 term = term[1:-1]

zproject/computed_settings.py

@@ -255,7 +255,7 @@ SILENCED_SYSTEM_CHECKS = [
 ########################################################################
 
 # Zulip's Django configuration supports 4 different ways to do
-# Postgres authentication:
+# PostgreSQL authentication:
 #
 # * The development environment uses the `local_database_password`
 #   secret from `zulip-secrets.conf` to authenticate with a local
@@ -264,18 +264,18 @@ SILENCED_SYSTEM_CHECKS = [
 #
 # The remaining 3 options are for production use:
 #
-# * Using Postgres' "peer" authentication to authenticate to a
+# * Using PostgreSQL's "peer" authentication to authenticate to a
 #   database on the local system using one's user ID (processes
 #   running as user `zulip` on the system are automatically
 #   authenticated as database user `zulip`).  This is the default in
 #   production.  We don't use this in the development environment,
 #   because it requires the developer's user to be called `zulip`.
 #
-# * Using password authentication with a remote Postgres server using
+# * Using password authentication with a remote PostgreSQL server using
 #   the `REMOTE_POSTGRES_HOST` setting and the password from the
 #   `postgres_password` secret.
 #
-# * Using passwordless authentication with a remote Postgres server
+# * Using passwordless authentication with a remote PostgreSQL server
 #   using the `REMOTE_POSTGRES_HOST` setting and a client certificate
 #   under `/home/zulip/.postgresql/`.
 #

zproject/prod_settings_template.py

@@ -434,7 +434,7 @@ ENABLE_GRAVATAR = True
 # and uncomment the following line.
 #DEFAULT_AVATAR_URI = '/local-static/default-avatar.png'
 
-# To access an external Postgres database you should define the host name in
+# To access an external PostgreSQL database you should define the host name in
 # REMOTE_POSTGRES_HOST, port in REMOTE_POSTGRES_PORT, password in the secrets file in the
 # property postgres_password, and the SSL connection mode in REMOTE_POSTGRES_SSLMODE
 # Valid values for REMOTE_POSTGRES_SSLMODE are documented in the