diff --git a/Dockerfile-postgresql b/Dockerfile-postgresql index 653166fac7..d9bed4e451 100644 --- a/Dockerfile-postgresql +++ b/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. diff --git a/docs/overview/architecture-overview.md b/docs/overview/architecture-overview.md index 0cda91dab5..88bba8ea75 100644 --- a/docs/overview/architecture-overview.md +++ b/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 -persistent data, that is, data that's expected to live beyond a user's -current session. Starting with Zulip 3.0, new Zulip installations -will install modern Postgres release rather than using the version included -with the operating system. +PostgreSQL is the database that stores all persistent data, that is, +data that's expected to live beyond a user's current session. +Starting with Zulip 3.0, new Zulip installations will install modern +PostgreSQL release rather than using the version included with the +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. diff --git a/docs/overview/changelog.md b/docs/overview/changelog.md index 2ab9d0ddb5..1e526967a1 100644 --- a/docs/overview/changelog.md +++ b/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 - Postgres repository by default, rather than using the default - Postgres version included with the operating system. Existing Zulip - installations will continue to work with Postgres 10; this detail is +- This release switches Zulip to install PostgreSQL 12 from the upstream + PostgreSQL repository by default, rather than using the default + PostgreSQL version included with the operating system. Existing Zulip + 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. diff --git a/docs/production/deployment.md b/docs/production/deployment.md index a79c12f2d2..c2db213140 100644 --- a/docs/production/deployment.md +++ b/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_PORT`: Port on the Postgres server. +* `REMOTE_POSTGRES_HOST`: Name or IP address of the PostgreSQL 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` diff --git a/docs/production/expensive-migrations.md b/docs/production/expensive-migrations.md index e893a523aa..c41452d885 100644 --- a/docs/production/expensive-migrations.md +++ b/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. -3. In the Postgres shell, run the following commands: + PostgreSQL database. +3. In the PostgreSQL shell, run the following commands: CREATE INDEX CONCURRENTLY zerver_usermessage_is_private_message_id diff --git a/docs/production/export-and-import.md b/docs/production/export-and-import.md index c40aa07ac6..092a237c49 100644 --- a/docs/production/export-and-import.md +++ b/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 - replication](#postgres-streaming-replication) and the [S3 file +* It's possible to set up [PostgreSQL streaming + 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` diff --git a/docs/production/install.md b/docs/production/install.md index dd4582f7fa..4c1408d115 100644 --- a/docs/production/install.md +++ b/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 diff --git a/docs/production/management-commands.md b/docs/production/management-commands.md index b961b8abca..f3cf8cf04a 100644 --- a/docs/production/management-commands.md +++ b/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 diff --git a/docs/production/postgres.md b/docs/production/postgres.md index d129a53a78..a94ba49d4e 100644 --- a/docs/production/postgres.md +++ b/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, -defaulting to Postgres 12 for new installations. +Starting with Zulip 3.0, Zulip supports using PostgreSQL 10, 11, or 12, +defaulting to PostgreSQL 12 for new installations. -Previous versions of Zulip used whatever version of Postgres was -included with the base operating system (E.g. Postgres 12 on Ubuntu +Previous versions of Zulip used whatever version of PostgreSQL was +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 -Postgres 12][upgrade-postgres], as may drop support for older Postgres +that installations currently using older PostgreSQL releases [upgrade to +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` -variable in /etc/zulip/settings.py, and configuring Postgres +dedicated PostgreSQL server by setting the `REMOTE_POSTGRES_HOST` +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. diff --git a/docs/production/requirements.md b/docs/production/requirements.md index 028276dcf2..bb6afb3c2d 100644 --- a/docs/production/requirements.md +++ b/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 diff --git a/docs/production/troubleshooting.md b/docs/production/troubleshooting.md index bccdb5222e..b2d25e8e05 100644 --- a/docs/production/troubleshooting.md +++ b/docs/production/troubleshooting.md @@ -141,11 +141,11 @@ problems and how to resolve them: `; 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 - have its Postgres server upgraded (and thus restarted). + moment a new PostgreSQL release is published, your Zulip server will + 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_replication_lag`: Checks whether Postgres streaming +* `check_postgresql_backup`: Checks status of PostgreSQL backups. +* `check_postgresql_replication_lag`: Checks whether PostgreSQL streaming replication is up to date. Standard server monitoring: diff --git a/docs/production/upgrade-or-modify.md b/docs/production/upgrade-or-modify.md index bd26503f79..776c5b87bb 100644 --- a/docs/production/upgrade-or-modify.md +++ b/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. diff --git a/docs/subsystems/analytics.md b/docs/subsystems/analytics.md index 32676dbb28..9ba9f534da 100644 --- a/docs/subsystems/analytics.md +++ b/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 diff --git a/docs/subsystems/dependencies.md b/docs/subsystems/dependencies.md index e904bf18d8..fbc3a9c324 100644 --- a/docs/subsystems/dependencies.md +++ b/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 diff --git a/docs/subsystems/schema-migrations.md b/docs/subsystems/schema-migrations.md index 148e64e0a2..8d86481cd2 100644 --- a/docs/subsystems/schema-migrations.md +++ b/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 diff --git a/docs/subsystems/settings.md b/docs/subsystems/settings.md index ed8a15f626..ae0da5fe3b 100644 --- a/docs/subsystems/settings.md +++ b/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 diff --git a/docs/testing/philosophy.md b/docs/testing/philosophy.md index 5c8f048c9a..dd41e2f734 100644 --- a/docs/testing/philosophy.md +++ b/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 diff --git a/puppet/zulip/files/nagios_plugins/zulip_postgresql/check_postgresql_replication_lag b/puppet/zulip/files/nagios_plugins/zulip_postgresql/check_postgresql_replication_lag index 6669a96e39..a4834800d7 100755 --- a/puppet/zulip/files/nagios_plugins/zulip_postgresql/check_postgresql_replication_lag +++ b/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 -connects to Postgres as has been granted the `pg_monitor` role. +replica PostgreSQL servers' xlog location. Requires that the user this +connects to PostgreSQL as has been granted the `pg_monitor` role. """ import re diff --git a/puppet/zulip/files/nagios_plugins/zulip_postgresql_backups/check_postgresql_backup b/puppet/zulip/files/nagios_plugins/zulip_postgresql_backups/check_postgresql_backup index 2bf3a66da5..3a49f28477 100755 --- a/puppet/zulip/files/nagios_plugins/zulip_postgresql_backups/check_postgresql_backup +++ b/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}') diff --git a/puppet/zulip/files/postgresql/pg_backup_and_purge b/puppet/zulip/files/postgresql/pg_backup_and_purge index 51c713ab54..f5b5ba0bc0 100755 --- a/puppet/zulip/files/postgresql/pg_backup_and_purge +++ b/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]) diff --git a/puppet/zulip/files/postgresql/process_fts_updates b/puppet/zulip/files/postgresql/process_fts_updates index dac753506c..4198e0d9a1 100755 --- a/puppet/zulip/files/postgresql/process_fts_updates +++ b/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 -# content of a message is modified, a Postgres trigger logs the +# Zulip manages its PostgreSQL full-text search as follows. When 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 diff --git a/puppet/zulip/manifests/postgresql_base.pp b/puppet/zulip/manifests/postgresql_base.pp index e4965ddadb..d167f2b057 100644 --- a/puppet/zulip/manifests/postgresql_base.pp +++ b/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' diff --git a/puppet/zulip/manifests/postgresql_common.pp b/puppet/zulip/manifests/postgresql_common.pp index d257149e4a..17f339aad1 100644 --- a/puppet/zulip/manifests/postgresql_common.pp +++ b/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 diff --git a/puppet/zulip_ops/files/nagios3/conf.d/services.cfg b/puppet/zulip_ops/files/nagios3/conf.d/services.cfg index 2fdca6f149..d1e0271c6c 100644 --- a/puppet/zulip_ops/files/nagios3/conf.d/services.cfg +++ b/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 diff --git a/scripts/lib/install b/scripts/lib/install index 7162007a51..824b3f0753 100755 --- a/scripts/lib/install +++ b/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 - # repository; this may conflict with the existing Postgres. + # We're going to install PostgreSQL from the PostgreSQL apt + # 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' diff --git a/scripts/setup/generate_secrets.py b/scripts/setup/generate_secrets.py index 6e1e757269..a9c0ecb0c6 100755 --- a/scripts/setup/generate_secrets.py +++ b/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`. diff --git a/scripts/setup/upgrade-postgres b/scripts/setup/upgrade-postgres index 82b63cc7e6..3f15dbdfff 100755 --- a/scripts/setup/upgrade-postgres +++ b/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 diff --git a/tools/lib/provision.py b/tools/lib/provision.py index 58d28b48fc..df19edf542 100755 --- a/tools/lib/provision.py +++ b/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( diff --git a/tools/setup/dev-vagrant-docker/Dockerfile b/tools/setup/dev-vagrant-docker/Dockerfile index 488aaacf52..990ceec96a 100644 --- a/tools/setup/dev-vagrant-docker/Dockerfile +++ b/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 \ diff --git a/zerver/lib/alert_words.py b/zerver/lib/alert_words.py index 42975c57ef..5d0d7f9d3a 100644 --- a/zerver/lib/alert_words.py +++ b/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() diff --git a/zerver/lib/migrate.py b/zerver/lib/migrate.py index 95b9723209..bcb1078569 100644 --- a/zerver/lib/migrate.py +++ b/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 {} diff --git a/zerver/management/commands/create_large_indexes.py b/zerver/management/commands/create_large_indexes.py index c49160d426..995ada1cdd 100644 --- a/zerver/management/commands/create_large_indexes.py +++ b/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 diff --git a/zerver/views/message_fetch.py b/zerver/views/message_fetch.py index b68f06f0f7..31d198cffc 100644 --- a/zerver/views/message_fetch.py +++ b/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] diff --git a/zproject/computed_settings.py b/zproject/computed_settings.py index 3a590a6668..7c28791751 100644 --- a/zproject/computed_settings.py +++ b/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/`. # diff --git a/zproject/prod_settings_template.py b/zproject/prod_settings_template.py index 0abc61992d..1b79e302a4 100644 --- a/zproject/prod_settings_template.py +++ b/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