Server setup and operation
This chapter discusses how to set up and run the database server, and its interaction with the operating system.
18.1 PostgreSQL user account
As with any server daemon that is accessible to the outside world, we also recommend running PostgreSQL under a separate user account. This user account should only own the data managed by the server, and should not be shared by other daemons (for example, using user nobody is a bad idea). We do not recommend installing executable files as belonging to this user, because compromised systems may then modify their own binary files.
To add a Unix user account to your system, look at a command useradd or adduser. Usually postgres is used (this account is also assumed in this book), but you can use another name.
18.2. Create a database cluster
Before you can do anything, you must initialize a database storage area on disk. We call it a database cluster (the term used by the SQL standard is directory cluster). A database cluster is a collection of multiple databases managed by a single instance of a running database server. After initialization, a database cluster will contain a database named postgres, which represents the default database used by functions, users, and third-party applications. The database server itself does not require the existence of the postgres database. Another database created for each cluster during the initialization process is called template1. As the name suggests, it will be used to create a template for subsequent databases; it should not be used for actual work (see Chapter 22 for more information on creating a new database in a cluster).
In file system terminology, a database cluster is a single directory where all data will be stored. We call it the data directory or data area. You choose where to store your data. There is no default location, but the /usr/local/pgsql/data或/var/lib/pgsql/datalocation is more popular. To initialize a database cluster, use the command initdb installed with PostgreSQL. The file system location of your database cluster is specified by the -D option,
for example:
$ initdb -D /usr/local/pgsql/data
Note that you must execute this command after logging in with a PostgreSQL user account (as shown in the previous section).
As an alternative to the -D option, you can set the environment variable PGDATA.
Another alternative is that you can run initdb through the pg_ctl program:
$ pg_ctl -D /usr/local/pgsql/data initdb
If you use pg_ctl to start and stop the server (see Section 18.3), this method may be more intuitive, thinking that pg_ctl will be the only command you use to manage the database server instance.
If the directory you specified does not exist yet, initdb will try to create it. Of course, this will fail if initdb does not have write permissions in the parent directory. It is generally recommended to let PostgreSQL users own the data directory and its parent directory, so that the above problem does not exist. If the desired parent directory does not exist, you will need to create it first. If the parent parent directory is not writable, use root privileges. Therefore, the process might look like this:
root# mkdir /usr/local/pgsql
root# chown postgres /usr/local/pgsql
root# su postgres
postgres$ initdb -D /usr/local/pgsql/data
If the data directory exists and already contains files, initdb will refuse to run. This can avoid accidentally overwriting an existing installation.
Because the data directory contains all the data stored in the database, the most important thing is to protect this directory from unauthorized access. Therefore, initdb will reclaim the access rights of all users except PostgreSQL users and groups can also be selected. When group access is enabled, it is read-only. It allows unauthorized users in the same group to act as the cluster owner, backup cluster data or perform other operations that only require read access permissions.
Note that when enabling or disabling group access in an existing cluster, you need to shut down the cluster and set all directories and files to the appropriate mode before restarting PostgreSQL. Otherwise, there will be multiple patterns in the data directory. The cluster can only be accessed by its owner. The appropriate mode should be 0700 for its directory and 0600 for ordinary files. To allow the cluster to be readable by the group, the appropriate mode should be 0750 for its directory and 0640 for normal files.
However, although the contents of the directory are secure, the default client authentication settings allow any local user to connect to the database or even become a database superuser. If you do not trust other local users, we recommend that you use one of the -W, -pwprompt or -pwfile options of initdb to assign a password to the database superuser. You can also specify -A md5 or -Apassword, so that the default trust authentication will not be used. Or modify the generated pg_hba.conf file after executing initdb and before starting the server for the first time (other possible methods include peer authentication or restricting connections with file system permissions.
init db also initializes the default area for the database cluster. Usually, it will just use the locale settings in the environment and apply them to the initialized database. You can specify a different area for the database; more information about this can be found in Section 23.1. The default sort order used in a particular database cluster is set by initdb. Although you can create a new database with a different sort order, the order used in the template database created by initdb cannot be changed (unless you delete and rebuild them). Using non-C or POSIX areas will also affect performance. Therefore, it is important to choose the right one the first time. init db also sets the default character set encoding for the database cluster. Usually the character set encoding should be chosen to match the locale.
Non-C and non-POSIX areas rely on the operating system's collation library for character set sorting. This controls the sorting of the keys stored in the index. For this reason, it is impossible to switch a cluster to an incompatible version of the collation library through snapshot recovery, binary stream replication, changing a different operating system, or upgrading the operating system.
18.2.1. Use of Secondary File System
Many installations create their database clusters on the file system (volume) instead of the machine's "root" volume. If you choose to do this, we do not recommend trying to use the top-level directory (mount point) of the secondary volume as the data directory. The best practice is to create a directory in the mount point directory owned by the PostgreSQL user, and then create the data directory in it. This can avoid permission problems, especially for operations such as pg_upgrade, and it can also ensure clean failure after the secondary volume is disconnected.
18.2.2. Use of Network File System
Many installations will create their database clusters on the network file system. Sometimes it is done directly through NFS, or through a network attached storage device (NAS) that uses NFS internally. PostgreSQL does not treat NFS file systems specially, that is, it assumes that NFS behaves exactly like locally connected devices. If the client or server NFS does not provide standard file system semantics, this will cause reliability issues (see https://www.time-travellers.org/shane/papers/NFS_considered_harmful.html).
Specifically, delayed (asynchronous) writing to the NFS server can cause data corruption issues. If possible, mounting the NFS file system as synchronous (no cache) can avoid this disaster. Also, we do not recommend soft-mounted NFS file systems.
Storage area networks (SAN) usually use non-NFS communication protocols and may or may not suffer from such disasters. It is recommended to consult the supplier’s documentation to understand the data consistency guarantee. PostgreSQL cannot be more reliable than the file system it uses.