Mirror
/
zulip
mirror of https://github.com/zulip/zulip.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

docs: Standardize on PostgreSQL, not Postgres.

This commit is contained in:
Alex Vandiver 2020-10-26 14:27:53 -07:00 committed by Tim Abbott
parent eaa99359b1
commit 1f7132f50d
35 changed files with 143 additions and 143 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
Dockerfile-postgresql
View File

@ -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.

12
docs/overview/architecture-overview.md
View File

@ -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.

32
docs/overview/changelog.md
View File

@ -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.

26
docs/production/deployment.md
View File

@ -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`

4
docs/production/expensive-migrations.md
View File

@ -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

16
docs/production/export-and-import.md
View File

@ -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`

2
docs/production/install.md
View File

@ -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

4
docs/production/management-commands.md
View File

@ -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

46
docs/production/postgres.md
View File

@ -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.

6
docs/production/requirements.md
View File

@ -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

14
docs/production/troubleshooting.md
View File

@ -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
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:

6
docs/production/upgrade-or-modify.md
View File

@ -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.

4
docs/subsystems/analytics.md
View File

@ -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

4
docs/subsystems/dependencies.md
View File

@ -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

2
docs/subsystems/schema-migrations.md
View File

@ -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

2
docs/subsystems/settings.md
View File

@ -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

2
docs/testing/philosophy.md
View File

@ -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

4
puppet/zulip/files/nagios_plugins/zulip_postgresql/check_postgresql_replication_lag
View File

@ -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

6
puppet/zulip/files/nagios_plugins/zulip_postgresql_backups/check_postgresql_backup
View File

@ -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}')

2
puppet/zulip/files/postgresql/pg_backup_and_purge
View File

@ -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])

10
puppet/zulip/files/postgresql/process_fts_updates
View File

@ -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

2
puppet/zulip/manifests/postgresql_base.pp
View File

@ -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'

2
puppet/zulip/manifests/postgresql_common.pp
View File

@ -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

26
puppet/zulip_ops/files/nagios3/conf.d/services.cfg
View File

@ -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

10
scripts/lib/install
View File

@ -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'

2
scripts/setup/generate_secrets.py
View File

@ -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`.

2
scripts/setup/upgrade-postgres
View File

@ -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

6
tools/lib/provision.py
View File

@ -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(

2
tools/setup/dev-vagrant-docker/Dockerfile
View File

@ -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 \

2
zerver/lib/alert_words.py
View File

@ -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()

2
zerver/lib/migrate.py
View File

@ -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 {}

2
zerver/management/commands/create_large_indexes.py
View File

@ -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

12
zerver/views/message_fetch.py
View File

@ -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]

8
zproject/computed_settings.py
View File

@ -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/`.
#

2
zproject/prod_settings_template.py
View File

@ -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