Shall PostgreSQL be started?

If this option is set to 'yes', the PostgreSQL server will be started automatically on system startup. Further you can control the database service by the service control entries from the PostgreSQL administration menu.

Default: START_POSTGRESQL15='no' This path points to the location, where the database files are kept in. If the path actually does not exist, it is automatically created and initialized by the configuration script. This is the encoding the database cluster is initialized with. Further it is the default encoding for newly created databases. Note that this setting only is honored when the cluster is initialized. This normally only is the case when the server is activated right after installation or when a different (empty) storage location has been selected. By default, PostgreSQL is only accessible from the local machine using Unix domain sockets. If you say 'yes' here, the postmaster service will also accept network connections according to the host access table. So if you want to access PostgreSQL from a remote machine, you should say 'yes' here. TCP/IP port for the postmaster service to listen on. This also affects the name of the named pipe for local unix domain socket connections.
Note: If you have multiple versions of postgresql running on the same machine simultaniously, the port numbers must be different to avoid that the servers interfere with each other.
The port defaults to '5432'. Maximum number of simultanious client connections. Enable SSL connections. This is required, if you want to use 'hostssl' as access type for host access table entries. Name of server certificate file. This file must have been previously created (at example using the certs package) and must reside within the /etc/ssl/certs folder. Name of server private key file. This file must have been previously created (at example using the certs package) and must reside within the /etc/ssl/certs folder. It must correspond with the obove given cert file. Enables client verification using the 'clientcert=verify-ca' or 'clientcert=verify-full' authentication options in the host access table. This is a file that contains a single or multiple root CA certificates (certificate bundle) you decide to trust when checking the validity of client certificates. This file must reside within the /etc/ssl/certs folder. Number of entries within the host access table.

The host access table is used to control access to the database server from the local machine and over the network. Please notice, that network access only works, if POSTGRESQL15_NETWORKING is set to 'yes'. Type of access the current entry is ment for. There are four possible access types available by now:
'local': Local access via unix domain sockets / the NETWORK field is ignored.
'host':  Access using TCP/IP sockets (encrypted or unencrypted at the client's choice).
'hostssl': $nbsp; Access using TCP/IP sockets (encrypted only).
'hostnossl': Access using TCP/IP sockets (unencryted only).
IP address and network mask of the host or network for which this host entry should take effect. Examples:
127.0.0.1/32:   The local machine using TCP/IP.
192.168.0.0/24: All machines within the specified address range.

PLEASE NOTE: If this entry is of the 'host' type (i.e. network access) this option must me specified. Otherwise you can leave this field empty. If a 'host'-entry is found and no network/host is given, the localhost (127.0.0.1/32) is used as default. The authentication method a client should use to authenticate the database user. There are nine different methods available (for easy setup, you should use 'trust' or 'scram-sha-256'):
'trust': Always trust the user - do not authenticate at all.
'reject': Never trust the user.
'scram-sha-256': Challenge-response authentication scheme based on RFC7677.
'md5': Challenge-response authentication scheme based on md5 hash.
'krb4': Use Kerberos 4 for authentication.
'krb5': Use Kerberos 5 for authentication.
'ident': Use the ident lookup for authentication.
'pam': Use pam for user authentication.
Name of the database this entry is ment for. Use 'all' as a wildcard for all databases. Name of the user this entry is ment for. Use 'all' as a wildcard for all users. Strategy used to verify SSL client certificates. This only is meaningful and effective, if both POSTGRESQL15_ENABLE_SSL and POSTGRESQL15_SSL_CLIENT_VERIFY are enabled and further the type 'hostssl' is selected for this access table entry.
There are three possible settings for this option:
'none':        Means there is no verification of client certificates at all.
'verify-ca':   Forces the client certificate to be signed by a trusted CA.
'verify-full': Is like 'verify-ca' but also requires the CN to equal the users name.
Due to fragmentation of database files, the database server may suffer a sigificant performance slowdown, if the command VACUUM has't been executed for a long time. If this option is set to "yes", the database server constantly checks the fragmentation of it's data files and executes VACUUM by itself, if required. The performance of the database server depends mostly on the memory resources the server is allowed to request. The more memory is spend, the better the performance will be. The eisfair configuration simplifies the assignment of memory by offering three possible memory layouts (small, medium, large and huge). Please read the documentation to learn more about these profiles.
As a rule of thump, select the profile by the available memory of your server according to the following table:

small: ... to 512MB
medium: 512MB to 2GB
large: 2GB to 4GB
huge: 4GB to ...
Beside of memory there is another key factor that has influence on the servers performance: The way data is written (flushed) to disk. The eisfair configuration offers four different write modes (secure, normal, fast and nosync). On one hand you have the option to choose the most secure method (secure) with the result of poor performance, on the other hand you have the most insecure method (nosync) that delivers the best performance of all. For most users something in between (normal or fast) will be the best choice to take. Please read the documentation to learn more about the write mode. The way PostgreSQL produces log messages can be modified in some aspects, it this option is set to "yes". Controls which message levels are sent to the client. Valid values are DEBUG5, DEBUG4, DEBUG3, DEBUG2, DEBUG1, LOG, NOTICE, WARNING, ERROR, FATAL, and PANIC. Each level includes all the levels that follow it. The later the level, the fewer messages are sent. The default is NOTICE. Note that LOG has a different rank here than in SERVER_LOG_LEVEL. Controls which message levels are written to the server log. Valid values are DEBUG5, DEBUG4, DEBUG3, DEBUG2, DEBUG1, INFO, NOTICE, WARNING, ERROR, LOG, FATAL, and PANIC. Each level includes all the levels that follow it. The later the level, the fewer messages are sent to the log. The default is NOTICE. Note that LOG has a different rank here than in CLIENT_LOG_LEVEL. Controls the amount of detail written in the server log for each message that is logged. Controls if SQL statements are written to the server log or not. Using this setting, the point in time can be defined, where automatic backups shall take place.

Examples for valid settings are:
DayOfWeek Year-Month-Day Hour:Minute:Second
Mon,Tue *-*-01..04 12:00:00
Sat *-*-1..7 18:00:00
*-*-* 04:00:00

Read documentation for more information or consult systemd-time man page. Target directory for backup files. Number of databases to backup automatically. Name of the database to backup. Name of a privileged database user to perform the backup operation. Specifies how many copies of the backup file for the specified database are to be kept. A command that is executed before the backup begins. This can be a command to mount a removable backup disk to your filesystem. A command that is executed after the backup is complete. This can be a command to unmount a removable backup disk from your filesystem. Here you can provide an email address that received nofigication messages from the backup process. This only works, if the mail-packages has been installed.
If you don't want to be notified by email, you can leave this values blank. This specifies whether the entire database cluster should be dumped into a single backup archive in the course of a data backup. In addition to the individual databases, it - among other things - also backs up users and groups. Name of the database user who has sufficient access permissions to back up the entire database cluster. Since the user "postgres" always exists, this most of the time is a good choice. Specifies how many copies of the backup file for the database cluster are to be kept. Additionally (or alternatively) individual databases can be saved in separate archives in addition to the backup of the entire database cluster. This offers the advantage that these can also be restored or migrated individually. This option activates the backup of individual databases.