The user executing the pg_dump command does not have access permissions to the resource to be backed up. Use GRANT to set access permissions for the resource to be backed up for the user executing the pg_dump command , or execute the pg_dump command by specifying a superuser for the connecting user.

For details on the pg_dump command, refer to PostgreSQL Documentation > Part VI. Reference > PostgreSQL Client Applications > pg_dump.

Platform: Windows, Linux  |  Version: All versions

This happened because the user did not add the -w option or the --no-password option to pgx_dmpall. By using these options, the user won't be prompted for a password. For details on the max_connections parameter, refer to Fujitsu Enterprise Postgres Reference Guide > Chapter 3 - Server commands > 3.2 -pgx_dmpall.

To solve this issue, run pgx_dmpall with the -w option or the --no-password option. If either is used, one of the following configuration must also be in place.

• Using the pgpass.conf: Write the password in the %APPDATA%\postgresql\pgpass.conf file (where %APPDATA% is the application data subdirectory in the user's profile). For details, refer to PostgreSQL documentation > Part IV - Client interfaces > Chapter 32 - libpq-C library > 32.16 - The password file.
• Using the password file pg_hba.conf: Specify "trust" in the "auth-method" field of the pg_hba.conf file in the data directory for the database cluster. For details, refer to PostgreSQL documentation > Part III - Server administration > Chapter 20 - Client authentication > 20.1 The pg_hba.conf file.

These methods allow batch processing without password input.

Platform: Windows, Linux  |  Version: All versions

Fujitsu Enterprise Postgres databases can be backed up and recovered without stopping the database, either using WebAdmin or using pgx_dmpall for backup and pgx_rcvall for recovery. For details on backup, refer to Fujitsu Enterprise Postgres Operation Guide > Chapter 3 - Backing up the database. For details on recovery, refer to Fujitsu Enterprise Postgres Operation Guide > Chapter 15 - Actions when an error occurs. It is also possible to back up the database without stopping it using PostgreSQL pg_dump. For details, refer to PostgreSQL documentation > Part III - Server administration > Chapter 25 - Backup and restore.

Platform: Windows, Linux  |  Version: All versions

pgx_dmpall saves backup files to the directory set in backup_destination in postgresql.conf, so when saving the contents of the backup directory to another location, make sure you save all content of this backup directory. When restoring, restore the content of the backup directory to the same state as the source. For details, refer to Fujitsu Enterprise Postgres Reference Guide > Chapter 3 - Server commands > 3.2 - pgx_dmpall.

Platform: Windows, Linux  |  Version: All versions

In postgresql.conf, enable WAL archiving by setting wal_level to replica (or logical when using logical replication), archive_mode to on, and archive_command to 'cp %p <archive directory path>/%f'.

Platform: Windows, Linux  |  Version: All versions

You will need at least twice the amount of space used by the instance.

Platform: Windows, Linux  |  Version: All versions

This may be happening because the password to connect to the database server has not been preset, so you are being prompted to enter it and the psql command is waiting. To resolve this, preconfigure the password to connect to the database server by doing one of the following:

• Specify the password in the PGPASSWORD environment variable. For details, refer to PostgreSQL documentation > Part IV - Client interfaces > Chapter 32 - libpq-C library > 32.16 - The password file.
• Specify the password file. In Linux, create the .pgpass file in the home directory of the executing user and specify the password. In Windows, create the %APPDATA%\postgresql\pgpass.conf file and specify the password (where % APPDATA% refers to the Application Data directory in the user's profile). For details, refer to PostgreSQL documentation > Part IV - Client interfaces > Chapter 32 - libpq-C library > 32.16 - The password file, PostgreSQL documentation > Part III - Server administration > Chapter 20 - Client authentication, and PostgreSQL documentation > Part VI. Reference > PostgreSQL client applications > psql.

Platform: Windows, Linux  |  Version: All versions

This may be happening because you applied an emergency fix for the WebAdmin feature (GUI features) and have not set up WebAdmin afterwards. Refer to the emergency fix information file [Notes] to run the WebAdmin setup.

For details on WebAdmin setup, refer to Fujitsu Enterprise Postgres Installation and Setup Guide for Server > Appendix B - Setting up and removing WebAdmin > B.1 - Setting up WebAdmin > B.1.1 Setting up WebAdmin.

Platform: Windows, Linux  |  Version: All versions

The max_connections and max_prepared_transactions settings specified in postgresql.conf affect shared memory usage, which is allocated when the database server starts. The acquired shared memory is used for database connection and prepared transactions, etc.
Therefore, memory is consumed even when database access is not performed.

Platform: Windows, Linux  |  Version: All versions

User changes to be saved in the database cluster require restarting the cluster or reloading the configuration files to take effect.

• To reflect changes in pg_hba.conf, run pg_ctl reload from the command line or execute SELECT pg_reload_conf(); as the superuser.
• To reflect changes in recovery.conf, run pg_ctl restart from then command line on the standby server. Note that recovery.conf has been deprecated in version 12. Changes related to recovery on the standby database cluster instance must be specified in postgresql.conf, and might require restarting the database cluster instance.

Platform: Windows, Linux  |  Version: All versions

Yes, it is possible to change, but special care needs to be taken care, because it involves database cluster to be stopped and restarted, and it will cause outage to users. To change the data storage location, follow the steps below:

1. Keep your new data storage location ready (e.g., /var/lib/postgres12_backup) with the same permissions as the existing data storage location (/var/lib/postgres12).
2. Shut down your current database cluster instance.
3. Run pg_ctl stop or use your Fujitsu Enterprise Postgres service.
4. Copy files from the current data storage location to new one using rsync -av (-a preserves file and folder permissions at the new location, and –v displays verbose output). If rsync is not available on your system, then use the normal copy command.
   rsync -av /var/lib/postgres12/* /var/lib/postgres12_backup/
5. To reduce size of the data storage location, consider deleting old unwanted logs.
6. Rename the old data storage directory from /var/lib/postgres12 to /var/lib/postgres12_old.
7. (optional) Rename the new data folder from /var/lib/postgres12_backup to /var/lib/postgres12 to match the original name.
8. Update the data_directory parameter in postgresql.conf if it is still set to the previous data storage location.
9. Start the database cluster instance and validate the data.
   pg_ctl start -D /var/lib/postgres12

To change backup data storage location:

1. Change the backup_destination parameter in postgresql.conf.
   This parameter specifies the absolute path of the directory where pgx_dmpall will store backup data. It can only be set when specified on starting an instance - it cannot be changed dynamically, while an instance is active.

Platform: Windows, Linux  |  Version: All versions

The fatal error message displayed may be one of the following: FATAL: sorry, too many clients already, FATAL: remaining connection slots are reserved for non-replication superuser connections, or FATAL: too many connections for database "xxxx".

If the message displayed is FATAL: sorry, too many clients already, this happened because the number of connections to the database server has exceeded the max_connections parameter in postgresql.conf. Otherwise, this happened because the number of connections to the database server has exceeded the value in the formula max_connections - superuser_reserved_connections - after this value is exceeded, only superusers can connect:

Both parameters are specified in postgresql.conf. max_connections specifies the maximum number of concurrent connections to the database server (the defaults is 1000), and superuser_reserved_connections specifies the number of superuser connections reserved for database maintenance (the default is 3). To resolve this, increase the maximum number of concurrent connections specified in max_connections.

The maximum number of simultaneous connections is calculated as max_connections = max num of concurrent connections to instance + superuser_reserved_connections + max_wal_senders. max_wal_senders is set in postgresql.conf, and specifies the maximum number of concurrent WAL submission processes to the standby server (the default is 10).

When setting the parameters, keep in mind that increasing the maximum number of simultaneous connections may increase memory usage and affect performance. For details, refer to PostgreSQL documentation > Part III - Server administration > Chapter 19 - Server configuration > 19.3 - Connections and authentication > 19.3.1 - Connection settings and 19.6 - Replication > 19.6.1. Sending servers.

Note that formula for the maximum number of simultaneous connections is different when performing database multiplexing operations. For details, refer to Fujitsu Enterprise Postgres Cluster Operation Guide (Database Multiplexing) > Chapter 2 - Setting up database multiplexing mode > 2.4 - Setting up the primary server > 2.4.2 - Creating, setting, and registering the primary server instance

Platform: Windows, Linux  |  Version: All versions

In principle, this does not affect Fujitsu Enterprise Postgres functionalities as long as you are not changing the server IP or the user who manages Fujitsu Enterprise Postgres. However, if your IP changes because of attaching your server to a domain and the old IP was in use (e.g., pg_hba.conf, streaming replication, logical replication etc.), then make sure to update the IP accordingly.

Also, if you change the user who manages (starts or stops) Fujitsu Enterprise Postgres on the local machine to a domain user, then you must adapt this domain user to be the new owner of the database cluster, and hence you need to update the permissions of domain user so that it can manage the Fujitsu Enterprise Postgres database cluster files and directory.

Platform: Windows, Linux  |  Version: All versions

The WAL segment size can be changed when creating the instance using initdb. The default size of each WAL segment size is 16MB. initdb provides the option --wal-segsize to specify the size of WAL segment files when creating the instance.

You cannot change the WAL segment size after initializing the database cluster.

Platform: Linux  |  Version: All versions

Not all parameters are immediately reflected to database clusters — some require executing pg_ctl command with either reload or restart. Execute psql -c "SELECT name, context FROM pg_settings;" and check the value of context column in pg_settings system view.

The value of context indicates: for postmaster, restart is required, for sighup, superuser-backend, or backend, reload is required, and for superuser or user, changes can be applied without reload or restart. These can also be set within a session via SET command.

Platform: Windows, Linux  |  Version: All versions

You can change the system configuration parameters across the entire database cluster with ALTER SYSTEM SET parm-name = parm-value.

This command writes the given parameter value into the postgresql.auto.conf file. The value set with this command will be effective after the next server configuration reload or server restart.

Platform: Windows, Linux  |  Version: All versions

The archive_mode in the standby server's postgresql.conf may be set to on. Set it to always in the standby server's postgresql.conf.

For details, refer to the PostgreSQL documentation >Part III - Server Administration >Chapter 19 - Server Configuration >19.5 - Write Ahead Log >19.5.3 - Archiving.

Platform: Windows, Linux  |  Version: All versions

Conflicts may occur when max_standby_archive_delay and max_standby_streaming_delay are configured with values that are too low. Increase these settings in the standby server's postgresql.conf so that they exceed the SQL execution time.

For details, refer to the PostgreSQL documentation > Part III - Server Administration > Chapter 19 - Server Configuration > 19.6 - Replication > 19.6.3 - Standby Servers and Part III - Server Administration > Chapter 26 - High Availability, Load Balancing, and Replication > 26.4 - Hot Standby > 26.4.2 - Handling Query Conflicts.

For other product versions/levels, please refer to the corresponding manual sections.

Platform: Windows, Linux  |  Version: All versions

You can change the tablespace for tables and indexes using ALTER statements after creating a new table space. It is not necessary to delete the original data.

CREATE TABLESPACE new_tablespace LOCATION 'new_tablespace_directory';
ALTER TABLE table_name SET TABLESPACE new_tablespace;
ALTER INDEX index_name SET TABLESPACE new_tablespace;

For details, refer to PostgreSQL documentation > Part VI - Reference > SQL Commands > ALTER INDEX, ALTER TABLE, and CREATE TABLESPACE.

Platform: Windows, Linux  |  Version: All versions

A standby server is in read-only mode. It cannot generate new transaction IDs or write WAL (Write-Ahead Log) records. On a standby server, you can execute read-only SQL commands such as SELECT. Commands that modify data, such as INSERT, UPDATE, DELETE, CREATE, ALTER, and DROP, cannot be executed.

For details on SQL commands that can and cannot be executed on a standby server, refer to PostgreSQL Documentation > Part III - Server Administration > Chapter 26 - High Availability, Load Balancing, and Replication > 26.4 - Hot Standby > 26.4.1 - User's Overview and 26.4.3. Administrator's Overview.

Platform: Linux  |  Version: All versions

Fujitsu Enterprise Postgres creates a file named postmaster.pid when it starts, and removes it when it shuts down normally. If the database stops unexpectedly or is not shut down properly, this file may remain in the data directory. When Fujitsu Enterprise Postgres starts again, it detects the existing file and reports the error.

To solve this issue, ensure that no Fujitsu Enterprise Postgres process is running, then delete the postmaster.pid file from the data directory and start Fujitsu Enterprise Postgres again.

Note that the data directory is specified by the -D option of pg_ctl, or the PGDATA environment variable.

Platform: Windows, Linux  |  Version: All versions

The psql command is waiting for a database password to be entered. This usually happens when a password has not been configured in advance and the batch job cannot respond to the password prompt.

Configure the database password before running the batch job using one of the following methods:

• Option 1: Use a password file - in Linux, create the .pgpass file in the user’s home directory, and in Windows, create the pgpass.conf file in %APPDATA%\postgresql\.
• Option 2: Set the database password in the PGPASSWORD environment variable before running the batch job.

For details on password files and the PGPASSWORD environment variable, refer to the PostgreSQL Documentation > Part IV - Client Interfaces > Chapter 32 - libpq - C Library > 32.15 - Environment Variables > PGPASSWORD and 32.16 - The Password File. For details on client authentication and the psql command, refer to PostgreSQL Documentation > Part III - Server Administration > Chapter 20 - Client Authentication and Part VI - Reference > PostgreSQL Client Applications > psql.

Platform: Windows, Linux  |  Version: All versions

Fujitsu Enterprise Postgres provides two types of statistics information: PostgreSQL statistics and Fujitsu Enterprise Postgres statistics.

PostgreSQL statistics help monitor database activity, including table access information, index access information, buffer hit counts, block read counts, function execution counts, function execution times. This information can be used to check buffer cache efficiency, identify frequently accessed tables, and find slow-running functions.

Fujitsu Enterprise Postgres statistics include wait and lock information, which can help to identify performance bottlenecks.

For details on the statistics information that can be obtained, refer to the Fujitsu Enterprise Postgres Operation Guide > Chapter 7 - Routine Operations > 7.6 - Monitoring Database Activity and PostgreSQL Documentation > Part III - Server Administration > Chapter 27 - Monitoring Database Activity > 27.2 - The Cumulative Statistics System.

Platform: Windows, Linux  |  Version: All versions

Log slow SQL statements by setting the log_min_duration_statement parameter in postgresql.conf. Any SQL statement whose execution time exceeds the configured threshold will be written to the log.

To log execution plans that exceed the specified execution time, use the auto_explain module and set the auto_explain.log_min_duration parameter. This helps identify slow SQL statements, the execution plans used by the optimizer, and potential performance bottlenecks.

For details on how to use auto_explain, refer to PostgreSQL Documentation > Part III - Server Administration > Chapter 19 - Server Configuration > 19.8 - Error Reporting and Logging > 19.8.2 - When to Log > log_min_duration_statement, and Part VIII - Appendixes > Appendix F - Additional Supplied Modules and Extensions> F.3 - auto_explain.

Platform: Windows, Linux  |  Version: All versions

When investigating a performance issue, collect database statistics and activity information as soon as possible. Some information, such as active sessions, transactions, and locks, may be lost after a database restart or when processing completes. The following information is recommended:

• Server process information - Shows active client connections and database sessions.

  SELECT * FROM pg_stat_activity;

• Transaction information - Shows currently running transactions and their duration.

  SELECT pid,
         wait_event_type,
         wait_event,
         state,
         (current_timestamp - xact_start)::interval(3) AS duration,
         query
  FROM pg_stat_activity
  WHERE pid <> pg_backend_pid();

• Lock information - Shows sessions waiting for locks and the affected tables.

  SELECT l.locktype,
         c.relname,
         l.pid,
         l.mode,
         a.query,
         (current_timestamp - xact_start) AS duration
  FROM pg_locks l
  LEFT JOIN pg_stat_activity a ON l.pid = a.pid
  LEFT JOIN pg_class c ON l.relation = c.oid
  WHERE NOT l.granted
  ORDER BY l.pid;

Collecting this information can help to identify long-running queries, blocking sessions, lock contention, and resource bottlenecks.

Platform: Windows, Linux  |  Version: All versions

This may be because the CSV format file uses 0x00 as the NULL value. The COPY FROM command treats unquoted empty characters as NULL, rather than 0x00.

If the CSV format file uses 0x00 as the NULL value, replace it with an empty string. If you want to distinguish NULL values from empty characters, you can also specify the string representing them in the NULL option of the COPY FROM command, so replace 0x00 with the specified string. For details, refer to PostgreSQL documentation > Part VI - Reference > SQL commands > COPY

Platform: Windows, Linux  |  Version: All versions

Yes. By leveraging tablespaces, tables and indexes can be placed in separate areas.

For details, refer to the PostgreSQL documentation > Part III - Server administration > Chapter 22 - Managing databases > 22.6 - Tablespaces, Part VI - Reference > SQL commands > CREATE TABLESPACE, CREATE TABLE, and CREATE INDEX

Platform: Windows, Linux  |  Version: All versions

Due to the I/O latency in the WAL archive storage area, the disk containing WAL is full and WAL cannot be written because the copy speed to the archive area is slower than the rate at which WAL data is generated. Consider expanding the capacity of the disk that store WAL files, reducing the frequency of database update, or using faster disks for WAL archiving.

• Check the error message in postgresql.log. It will contain an error message stating that the server has stopped because the disk was full and that the system could not write WAL, for example: PANIC: could not write to file "pg_wal/waltemp.4920": No space left on device
• Compare the WAL generation rate and backup rate. Check the WAL generation rate with timestamp intervals of each WAL file under the pg_wal directory, check the backup rate with timestamp intervals of each file under the archived_wal directory, and confirm that the WAL generation rate is larger than backup rate.

As long as your environment can keep up with the average speed of the WAL generation of the server, the processing speed of the command for archiving is not important. Normal operations continue even if the archive process is slightly delayed, but note that a significantly slower archive process increases the amount of data lost in the event of a disaster. This also means that many segment files waiting to be archived will be stored in $PGDATA/pg_wal, which may cause the disk to be full. It is recommended that you monitor the archive process to ensure that it is working as intended.

For details, refer to PostgreSQL documentation > Part III - Server administration > Chapter 25 - Backup and restore > 25.3.1 - Setting up WAL archiving. You can also refer to our blog post How to solve the problem if pg_wal is full.

Platform: Windows, Linux  |  Version: All versions

Before clearing space in the backup data directory, one thing to note is the scenario where archiving log is enabled and archive logs are stored in the backup data directory. Once this destination runs out of space, the actual data directory will be filled with WAL logs. If that data directory runs out of space, the database may be unavailable. So, this must be urgently taken care of.

If you run out of space in the backup data directory, the first step is to delete unnecessary files on it. If that does not solve the problem, temporarily save backup data to another location with sufficient space, or replace the disk containing the backup data directory with a disk with more capacity.

For details, refer to Fujitsu Enterprise Postgres Operation Guide > Chapter 15 - Actions when an error occurs > 15.7 - Actions in response to insufficient space on the backup data storage destination .

Platform: Linux  |  Version: All versions

You can import data into the database by using the COPY statement with the -c option of the psql command, for example: $ psql -d db-name -c "COPY table1 FROM 'import_data.csv' DELIMITER ','". For details, refer to PostgreSQL documentation > Part VI - Reference > SQL Commands > COPY

Platform: Windows, Linux  |  Version: All versions

Step 1: Identify whether the installed PostgreSQL is Fujitsu Enterprise Postgres or open-source software

Option 1: Check the default installation directory of Fujitsu Enterprise Postgres. List the content of the default installation directory of Fujitsu Enterprise Postgres (/opt/fsepvversionserver64). If the directory exists, and its sub-directories are not empty, then Fujitsu Enterprise Postgres is installed.

Option 2: Execute the pg_ctl command. Set the appropriate environment variables required to execute the Fujitsu Enterprise Postgres command pg_ctl, and then either check the server status with $ pg_ctl status -D data-directory or start the database server with $ pg_ctl start -D data-directory. If you can execute the command successfully, then it means that Fujitsu Enterprise Postgres is installed.

Option 3: Check the RPM packages. List the RPM packages related to Fujitsu Enterprise Postgres with $ rpm -qa | grep FJSVfsep. If packages with name starting with FJSVfsep are listed, then it means that Fujitsu Enterprise Postgres is installed. Note that RPM packages may differ depending on the components installed by the customer.

Step 2: Verify the details of the installed product.

Option 1: List the Fujitsu middleware products installed on the machine. As the root user, execute # /opt/FJSVcir/cimanager.sh, then verify the product names and versions with /opt/FJSvVcir/cimanager.sh.

Option 2: Check the RPM package details. Display information about the installed package with $ rpm -qi FJSVfsep-SV-version, and verify details such as installation date/time and installation directory.

Step 3: Verify if the Fujitsu Enterprise Postgres process is running

List the PostgreSQL-related processes currently running with $ ps -ef | grep postgres. If the postgres process of Fujitsu Enterprise Postgres installation directory /opt/fsepvversionserver64/bin/postgres is listed, then it means that Fujitsu Enterprise Postgres process has started.

Step 4: Verify the patches applied to the Fujitsu Enterprise Postgres server

If you have applied patches with the downloaded RPM, list details of the applied patches with $ rpm -qa | grep prefix of product patches and rpm -qi <prefix of product patches>, and Verify that the latest patches have been applied to the database server.

Platform: Linux  |  Version: All versions

You must use the foreign data wrapper postgres_fdw, which is built-in to Fujitsu Enterprise Postgres and provides read/write support. For details, refer to our PostgreSQL Insider article Linking to foreign data using foreign data wrappers.

Platform: Windows, Linux  |  Version: All versions

Yes. All identifiers, including column names, are converted to lowercase in Fujitsu Enterprise Postgres, unless enclosed by double quotes. Identifiers created with double-quotes retain their original capitalization.

Platform: Windows, Linux  |  Version: All versions

In psql, use the meta-commands \dt, \di, \l, and \du, respectively. This information can also be obtained from the system views pg_tables, pg_indexes, pg_database, and pg_user, respectively.

Platform: Linux  |  Version: All versions

You can check with SELECT EXISTS (SELECT 1 FROM information_schema.tables WHERE table_schema='schema-name' AND table_name='table-name'); or with the meta-command \dt schema-name table-name.

Platform: Linux  |  Version: All versions

Database Multiplexing Operation Error:
WARNING: An abnormality was detected in the monitoring target "database process (postmaster)": Unresponsive: failed to create socket: xxxxx (xxx)xxx (MCA00019)
PostgreSQL Error:
FATAL: sorry, too many clients already

Mirroring Controller attempts to connect to the database server for OS/server and database process liveness monitoring (heartbeat). This connection failed due to exceeding the maximum number of connections on the database server. As a result, Mirroring Controller determined that the database server was stopped or unresponsive and initiated a failover. To avoid this, review the maximum number of connections specified in the superuser_reserved_connections and max_connections parameters of the primary server's postgresql.conf file.

For details, refer to Fujitsu Enterprise Postgres Cluster Operation Guide (Database Multiplexing) > Part 1: Database Multiplexing Operation > Chapter 2 - Database Multiplexing Operation Setup > 2.4 Primary Server Setup > 2.4.2 Creating, Configuring, and Registering a Primary Server Instance

Platform: Windows, Linux  |  Version: All versions

A permission error may have occurred. User-specific or other product's (work) files are created under the database cluster's data directory. Fujitsu Enterprise Postgres backs up the data directory, tablespaces, and configuration files when the pgx_dmpall command is executed. However, if the data directory contains work files that the PostgreSQL user account executing the pgx_dmpall command does not have access permissions to, this error may occur.

To avoid this so not create user-specific or other product's (work) files under the data directory, and delete or move user-specific or other product's (work) files from under the data directory.

Platform: Windows, Linux  |  Version: All versions

Yes, it is by design. Stopping the Mirroring Controller using the mc_ctl stop command means that the customer themselves is stopping the Mirroring Controller. Therefore, even if the automatic switchover/detachment function is enabled (by executing mc_ctl start with the -f option, or by executing mc_ctl enable-failover), a switchover will not occur. To perform a switchover, execute the mc_ctl switch command.

For details, refer to Fujitsu Enterprise Postgres > Reference > Chapter 4: Mirroring Controller Commands > 4.2 mc_ctl and Cluster Operation Guide (Database Multiplexing) > Part 1: Database Multiplexing Operation > Chapter 3: Database Multiplexing Operation > 3.4 Manual Switchover of Primary Server

Platform: Windows, Linux  |  Version: All versions

To return to database multiplexing operation, the standby server (old primary server) needs to be rebuilt.

To rebuild the old primary server, refer to Fujitsu Enterprise Postgres Cluster Operation Guide (Database Multiplexing) > Part 1: Database Multiplexing Operation > Chapter 4: Handling Abnormalities in Database Multiplexing Operation > 4.1 Handling Degraded Operation > 4.1.1 Operation after switchover during degraded operation

[Note] There are precautions when rebuilding a standby server using the pg_rewind command.
The timeline IDs of the source server and target server for the pg_rewind command must be different. However, immediately after the primary server (old standby server) is promoted, pg_rewind may not be executable because the application processing of unapplied update transaction logs and the subsequent checkpoint processing to update the timeline ID have not yet completed. Therefore, execute the pg_rewind command after unapplied update transaction logs are cleared and the timeline ID update is complete on the primary server (old standby server).2
After executing the pg_rewind command, perform the following.

• Set the necessary parameters for the standby server in the standby server's (old primary server's) postgresql.conf file.
  For details, refer to Fujitsu Enterprise Postgres Cluster Operation Guide (Database Multiplexing) > Part 1: Database Multiplexing Operation > Chapter 2 - Database Multiplexing Operation Setup > 2.5 Standby Server Setup > 2.5.2 Creating, Configuring, and Registering a Standby Server Instance > Table 2.5 Parameters to set
• Create a standby.signal file on the standby server (old primary server).
• Use the ALTER SYSTEM SET statement to change the connection string specified in the primary_conninfo parameter of the postgresql.auto.conf file.

Platform: Windows, Linux  |  Version: All versions

The connection/disconnection logs are being output for the database process's anomaly monitoring in the database multiplexing operation (Mirroring Controller).
These logs are output approximately every second, depending on the settings of the following parameters in the database multiplexing operation's server definition file:
db_instance_check_interval = 800
db_instance_check_timeout = 1

It is not possible to suppress only the connection/disconnection logs for the database process's anomaly monitoring in database multiplexing operation.
The number of outputs can be reduced by changing the setting of the following parameter in the database multiplexing operation's server definition file:
db_instance_check_interval

For details, refer to Cluster Operation Guide (Database Multiplexing) > Part 1: Database Multiplexing Operation > Chapter 2 - Database Multiplexing Operation Setup > 2.11 Tuning > 2.11.4 Tuning for optimal anomaly monitoring and degraded operation > 2.11.4.2 Anomaly Monitoring Tuning for Database Processes

Platform: Windows, Linux  |  Version: All versions

The pg_dump command outputs bytea type data as characters. Therefore, the bytea type data was converted to characters, exceeding the quantitative limit (1 gigabyte) for character data length. For details on the output format of bytea type data, refer to PostgreSQL Documentation > Part II. The SQL Language > Chapter 8. Data Types > 8.4. Binary Data Types. For details on supported data types and quantitative limits, refer to Fujitsu Enterprise Postgres 15 > Installation Guide (Server Edition) > Appendix G: Quantitative Limits > Table G.5 Supported Data Types and Attributes.

To resolve this, save the data of the table by specifying binary in the FORMAT parameter of the COPY command. Since the COPY command only saves data, use the pg_dump command with the -s option or --exclude-table-data to also save the table definition. For details on pg_dump refer to PostgreSQL Documentation > Part VI. Reference > SQL Commands > COPY > PostgreSQL Client Applications > pg_dump

Platform: Windows, Linux  |  Version: All versions

standby.signal does not exist on the standby server. To resolve this, create standby.signal in the database cluster's data directory on the standby server.

For details on standby.signal, refer to PostgreSQL Documentation > Part III. Server Administration > Chapter 26. High Availability, Load Balancing, and Replication > 26.2. Log-Shipping Standby Servers > 26.2.4. Setting Up a Standby Server and Cluster Operation Guide (Database Multiplexing) > Part 1: Database Multiplexing Operation > Chapter 2 - Database Multiplexing Operation Setup > 2.5 Standby Server Setup > 2.5.2 Creating, Configuring, and Registering a Standby Server Instance

When creating a replica of the primary server instance on the standby server, if the -R option is specified during pg_basebackup command execution, standby.signal will be created, and the minimum necessary items (primary_conninfo) will also be set in postgresql.auto.conf.

Platform: Windows, Linux  |  Version: All versions

A query can be canceled using the pg_cancel_backend function. A connection can be forcibly disconnected using the pg_terminate_backend function or pgAdmin.
With the pg_cancel_backend and pg_terminate_backend functions, the target query to be canceled or the target connection to be disconnected is specified by its process ID. The process ID can be confirmed using the pg_stat_activity view or the OS's ps command.

For details, refer to Fujitsu Enterprise Postgres > Operation Guide > Chapter 14: Handling Abnormalities > 14.4 Handling Application Abnormalities and PostgreSQL Documentation > Part II. The SQL Language > Chapter 9. Functions and Operators > 9.28. System Administration Functions > 9.28.2. Server Signaling Functions.

Platform: Windows, Linux  |  Version: All versions

The application may not have not disconnected from the database, leaving unnecessary connections and exceeding the maximum number of simultaneous connections to the database server. The maximum number of simultaneous connections to the database server is specified by the max_connections parameter in postgresql.conf. The default is 100.

To avoid this, add a process to the application to disconnect from the database. If a process to disconnect from the database is already implemented, review the maximum number of simultaneous connections specified in the max_connections parameter of postgresql.conf. For details on disconnecting from the database, refer to PostgreSQL Documentation > Part IV. Client Interfaces > Chapter 34. ECPG - Embedded SQL in C > 34.2. Managing Database Connections

This is a detailed explanation for Embedded SQL in C. If other interfaces are used, refer to the manual for the corresponding programming language.

For details on the max_connections parameter, refer to PostgreSQL Documentation > Part III. Server Administration > Chapter 19. Server Configuration > 19.3. Connections and Authentication > 19.3.1. Connection Settings

Platform: Windows, Linux  |  Version: All versions

Fujitsu Enterprise Postgres may not have shut down properly last time (including shutdown in immediate shutdown mode), and crash recovery is taking a long time during the subsequent Fujitsu Enterprise Postgres startup. If database system was not properly shut down; automatic recovery in progress is output in the Fujitsu Enterprise Postgres log, crash recovery is in progress.

Wait until crash recovery completes and Fujitsu Enterprise Postgres startup finishes.
By reducing the values of max_wal_size and checkpoint_timeout in the postgresql.conf file, and increasing the checkpoint frequency, you can shorten the crash recovery processing time. However, increasing the checkpoint frequency will increase I/O load, so set appropriate values after considering your operations.

For details on Enterprise Postgres shutdown, refer to PostgreSQL Documentation > Part III. Server Administration > 18. Server Setup and Operation > 18.5. Shutting Down the Server. For details on max_wal_size and checkpoint_timeout, refer to PostgreSQL Documentation > Part III. Server Administration > 19. Server Configuration > 19.5. Write Ahead Log > 19.5.2. Checkpoints

Platform: Windows, Linux  |  Version: All versions

Temporary table management information remains in the Fujitsu Enterprise Postgres system catalog due to a Fujitsu Enterprise Postgres crash or some other reason. The autovacuum function detects this temporary table management information and outputs the message.

No action is required. The relevant temporary table management information will be automatically collected later. If you want to collect it immediately, delete the schema output in "@1@" of the message using a database user with superuser privileges.

Platform: Windows, Linux  |  Version: All versions

The application may not have disconnected from the database, leaving unnecessary connections, and exceeding the maximum number of connections in the connection pool. When a connection request exceeds the maximum number of connections in the connection pool, it waits until an available connection is found. If no available connection is found and the connection timeout period is exceeded, the connection request results in a timeout error.

To resolve this, check for long-waiting connections and disconnect any unnecessary connections. Also, review the application to see if there are any missing processes for disconnecting from the database, and add such processes. If processes for disconnecting from the database are already implemented, review the maximum number of connections in the connection pool (specified by the Maximum Pool Size keyword; default is 100.) specified in the connection string.

For details on how to check and disconnect existing connections, refer to Fujitsu Enterprise Postgres > Operation Guide > Chapter 7: Routine Operations > 7.4 Monitoring Application Connection Status and Chapter 10: Handling Abnormalities > 10.4 Handling Application Abnormalities. For details on connection strings, refer to Fujitsu Enterprise Postgres > Application Development Guide > Chapter 4: .NET Data Provider > 4.3 Connecting to the Database > 4.3.4 Connection String

Platform: Windows, Linux  |  Version: 9.5, 9.6

PANIC: could not write to file "pg_wal/xlogtemp.xxxx": No space left on device
LOG: WAL writer process (PID xxxx) was terminated by signal 6: Aborted

There is not sufficient disk space in the directory where the transaction log is stored. Furthermore, if archive_mode is enabled, insufficient disk space in the backup data storage directory may also have caused insufficient space in the transaction log storage directory (archive_mode is specified by the archive_mode parameter in postgresql.conf. If an instance is created with WebAdmin, it is enabled automatically). Transaction logs are not deleted until they can be archived to the backup data storage directory. If the disk space in the backup data storage directory is insufficient, transaction logs cannot be archived, leading to a shortage of space in the transaction log storage directory.

If the disk space in the backup data storage directory is insufficient, the following error will be output to the Fujitsu Enterprise Postgres log:
could not write to file "/backup_data_storage_directory/archive_log_storage_directory/xxxxx": No space left on device

/backup_data_storage_directory/archive_log_storage_directory is specified by the archive_command parameter in postgresql.conf.

To avoid this, ensure there is free space on the disk where the transaction log storage directory is located. If archive_mode is enabled and the disk space in the backup data storage directory is insufficient, also ensure free space on the disk where the backup data storage directory is located. For details, refer to Fujitsu Enterprise Postgres > Operation Guide > Chapter 7: Routine Operations > 7.2 Monitoring Disk Usage and Ensuring Free Space and Chapter 14: Handling Abnormalities > 14.7 Handling Insufficient Backup Data Storage Space > 14.8 Handling Insufficient Transaction Log Storage Directory Space

Platform: Linux  |  Version: All versions

The cause is likely that the pgx_keystore command was executed by a user account other than the one that starts Fujitsu Enterprise Postgres.
When the pgx_keystore command is executed, a file named keystore.aks is created in the keystore storage directory. If the pgx_keystore command is executed by a user account other than the one that starts Fujitsu Enterprise Postgres, starting Fujitsu Enterprise Postgres will fail because the user account that starts Fujitsu Enterprise Postgres does not have permission to access the keystore.aks file.

To avoid this, delete the keystore.aks file in the keystore storage directory, then re-execute the pgx_keystore command as the user account that starts Fujitsu Enterprise Postgres. For details, refer to Fujitsu Enterprise Postgres > Operation Guide > Chapter 5 - Protecting Stored Data with Transparent Data Encryption > 5.6 - Keystore Management > 5.6.3 - Enabling Automatic Keystore Opening

Platform: Windows, Linux  |  Version: All versions

FATAL: sorry, too many clients already

If the message above is displayed, the number of connections to the database server exceeded max_connections.

FATAL: remaining connection slots are reserved for non-replication superuser connections

FATAL: too many connections for database xxxx

If one of the messages above is displayed, the number of connections to the database server exceeded the value of max_connections - superuser_reserved_connections. When this value is exceeded, only superuser connections are allowed.

max_connections specifies the maximum number of concurrent connections to the database server (default: 100), and superuser_reserved_connections specifies the number of superuser connections reserved for database maintenance (default: 3). Both parameters are specified in postgresql.conf.

To solve this, increase the value of max_connections to maximum number of concurrent connections to the instance + superuser_reserved_connections + max_wal_senders. max_wal_senders specifies the maximum number of concurrent WAL sender processes to standby servers (default: 10; only add if using Fujitsu Enterprise Postgres 11 or earlier). Note that increasing the maximum number of concurrent connections may increase memory usage and affect performance. Set an appropriate value based on your business requirements.

For details, refer to PostgreSQL Documentation > Part III. Server Administration > Chapter 19. Server Configuration > 19.3. Connections and Authentication > 19.3.1. Connection Settings 19.6 - Replication > 19.6.1 - Sending Servers. When operating database multiplexing, the formula for estimating the maximum number of concurrent connections differs. Refer to Fujitsu Enterprise Postgres Cluster Operation Guide (Database Multiplexing) > Chapter 2 - Database Multiplexing Operation Setup > 2.4 - Primary Server Setup > 2.4.2 - Creating, Configuring, and Registering a Primary Server Instance

Platform: Windows, Linux  |  Version: All versions

If backup data storage capacity is insufficient, first delete unnecessary files on the disk where the backup data storage directory is located. If the problem cannot be resolved by deleting unnecessary files, temporarily delete backup data or replace the disk where the backup directory is located with a larger capacity disk. For details, refer to Fujitsu Enterprise Postgres > Operation Guide > Chapter 14: Handling Abnormalities > 14.7 Handling Insufficient Backup Data Storage Capacity

Platform: Windows, Linux  |  Version: All versions

schema "@1@" already exists
index "@1@" does not exist
cannot drop @1@ because other objects depend on it

The -c or -C option may have been specified incorrectly or omitted when executing the pg_restore command. Consider whether to specify these options, taking into account the creation status of database objects in the restore destination and how to handle database objects if they already exist in the restore destination (recreate/use as-is).

-c (--clean option) outputs commands to delete database objects at the beginning of the script file, and -C (--create option) outputs commands to create the database itself at the beginning of the script file (-C cannot be specified with the pg_dumpall command; if it is specified simultaneously with -c, the database is deleted and then recreated. The specification of -c and -C with pg_dump and pg_dumpall commands is only effective when extracting to a script file (plain text format). When extracting to an archive file (archive format), consider specifying them with the pg_restore command.

If -c is specified with pg_dump or pg_dumpall commands, and the restore results in an error due to a non-existent or undeletable database object, no action is required if the restore completed successfully. If -c and -C are not specified with pg_dump or pg_dumpall commands, and the restore results in an error that a database object already exists, you can simply use the current script file to perform the restore if you delete the objects to be restored that are included in the script file beforehand.

For details, refer to PostgreSQL Documentation > Part VI. Reference > PostgreSQL Client Applications > pg_dump and pg_restore

Platform: Windows, Linux  |  Version: All versions

schema "@1@" already exists
index "@1@" does not exist
cannot drop @1@ because other objects depend on it

The -c or -C option may have been specified incorrectly or omitted when executing the pg_restore command. Consider whether to specify these options, taking into account the creation status of database objects in the restore destination and how to handle database objects if they already exist in the restore destination (recreate/use as-is).

-c (--clean option) deletes database objects before restoring, and -C (--create option) creates the database before restoring (if specified simultaneously with -c, the database is deleted and then recreated). If -c is specified and errors occur due to non-existent or undeletable database objects, no action is required if the restore completed successfully. For details, refer to PostgreSQL Documentation > Part VI. Reference > PostgreSQL Client Applications > pg_dump and pg_restore

Platform: Windows, Linux  |  Version: All versions

The command may have been executed from a command prompt not launched with administrator privileges.

Execute the pgx_dmpall command from a command prompt launched with administrator privileges.If the instance administrator is a user belonging to the Administrators group, the pgx_dmpall command must be executed from an Administrator: Command Prompt.

Platform: Windows  |  Version: All versions

The cause may be that postgres_fdw fetches a small number of rows per fetch, leading to a high number of communications with the external server and thus taking a longer time. By increasing fetch_size, which is a remote execution option of the postgres_fdw external data wrapper option, it is possible to reduce the number of communications with the external server.

For details, refer to PostgreSQL Documentation > Part VIII. Appendixes > Appendix F. Additional Supplied Modules > F.38. postgres_fdw > F.38.1. FDW Options of postgres_fdw > F.38.1.4. Remote Execution Options

Platform: Windows, Linux  |  Version: All versions

PREPARE TRANSACTION was executed while the max_prepared_transactions parameter in postgresql.conf was set to 0.

To avoid this, set the max_prepared_transactions parameter in postgresql.conf to 1 or greater. For details, refer to PostgreSQL Documentation > Part III. Server Administration > Chapter 19. Server Configuration > 19.4. Resource Consumption > 19.4.1. Memory

Platform: Windows, Linux  |  Version: All versions

The cause may be that WAL was generated because hint bits were updated during searches after data insertion. Hint bits are used to mark tuples that have been created, deleted, or both, by transactions that have been committed or aborted.

Resolve the issue by ensuring sufficient capacity in the archive WAL storage location or by not specifying the -k option (enable checksums) when executing the initdb command, and setting wal_log_hints in postgresql.conf to off  (however, in this case, the pg_rewind command will become unavailable).

For details, refer to PostgreSQL Documentation > Part III. Server Administration > Chapter 19. Server Configuration > 19.5. Write Ahead Log > 19.5.1. Settings

Platform: Windows, Linux  |  Version: All versions

The path to the pcp.conf configuration file may not have been specified when starting Pgpool-II. When starting Pgpool-II, specify the path to the pcp.conf configuration file using the -F option.

Platform: Windows, Linux  |  Version: 10 and later

A WAL segment that the standby server was supposed to receive has already been deleted (recycled) on the primary server.

To resolve this, recreate the standby server instance to recover. For details, refer to the manual: Fujitsu Enterprise Postgres Cluster Operation Guide (Database Multiplexing) > Part 1: Database Multiplexing Operation > Chapter 4: Handling Abnormalities in Database Multiplexing Operation > 4.1 Handling Degraded Operation

To avoid the error from occurring again, consider increasing the number of WAL segments retained on the primary server or using replication slots. For details, refer to Fujitsu Enterprise Postgres Cluster Operation Guide (Database Multiplexing) > Chapter 2 - Database Multiplexing Operation Setup > 2.11 - Tuning > 2.11.1 - Tuning for stabilizing database multiplexing operation and PostgreSQL Documentation > Part III. Server Administration > Chapter 26. High Availability, Load Balancing, and Replication > 26.2. Log-Shipping Standby Servers > 26.2.6. Replication Slots, respectively.

Platform: Windows, Linux  |  Version: All versions

The autovacuum execution was canceled due to a conflict with other SQL statement executions.

The conflicting table can be identified in the CONTEXT error information output on the line after ERROR: canceling autovacuum task. The conflicting SQL statement can be checked in the pg_stat_activity view. If DEFAULT or VERBOSE is specified for the log_error_verbosity parameter in postgresql.conf, it will be output as CONTEXT: automatic vacuum of table table_name

Since autovacuum is automatically re-executed, no action is required if the re-execution completes successfully. However, if re-execution continuously fails with this error, it indicates that a long transaction accessing the relevant table exists, and autovacuum is unable to operate. Review your application and resolve the long transaction.

For details on the log_error_verbosity parameter, refer to PostgreSQL Documentation > Part III. Server Administration > Chapter 19. Server Configuration > 19.8. Error Reporting and Logging > 19.8.3. What to Log. For details on autovacuum, refer to PostgreSQL Documentation > Part III. Server Administration > Chapter 24. Routine Database Maintenance Tasks > 24.1. Routine Vacuuming. For details on the pg_stat_activity view, refer to PostgreSQL Documentation > Part III. Server Administration > Chapter 27. Monitoring Database Activity > 27.2. The Cumulative Statistics System.

Platform: Windows, Linux  |  Version: All versions

The file descriptor limit was reached before the max_connections parameter limit was reached. When a client process establishes a connection to the database, file descriptors are consumed. Therefore, this occurs when the file descriptor limit is reached before the max_connections parameter limit in postgresql.conf. If necessary, modify the limits.conf settings.

For details on the max_connections parameter, refer to PostgreSQL Documentation > Part III. Server Administration > Chapter 19. Server Configuration > 19.3. Connections and Authentication > 19.3.1. Connection Settings

Platform: Linux  |  Version: All versions

You can check using the pg_stat_activity view or pgAdmin. For details, refer to Fujitsu Enterprise Postgres > Operation Guide > Chapter 7 - Routine Operations > 7.4 - Monitoring Application Connection Status.

Platform: Windows, Linux  |  Version: All versions

If synchronous replication is configured with a standby server, transaction commits may be waiting for WAL records to be replicated to the standby server.

Standby servers specified in the synchronous_standby_names parameter of the primary server's postgresql.conf will use synchronous replication.
If synchronous replication is configured with a standby server, and the synchronous_commit parameter of the primary server is set to remote_apply, on, or remote_write, then when COMMIT is executed on the primary server, transaction commits will wait until the corresponding WAL records are replicated to the standby server. For details on the synchronous_standby_names and synchronous_commit parameters, refer to PostgreSQL Documentation > Part III. Server Administration > Chapter 19. Server Configuration > 19.6. Replication > 19.6.2. Primary Server and 19.5. Write Ahead Log > 19.5.1. Settings .

To resolve this, check if there are any abnormalities in the standby server configured for synchronous replication or in the replication path.

Platform: Windows, Linux  |  Version: All versions

For both input from the client to the server and output from the server to the client, character code conversion using conversions defined by CREATE CONVERSION is executed according to the client encoding (client_encoding) setting for each session.

However, there are the following notes regarding the client_encoding value depending on the client application used:

• For Npgsql: The client_encoding during connection is specified by the ClientEncoding parameter. If it is  set to SJIS, the .NET side also needs to specify the Encoding parameter. The default value for client_encoding in Npgsql is UTF-8. The client encoding can be changed by modifying the PGCLIENTENCODING environment variable.
• For psql: If both standard input and standard output are terminals, the default value for psql's client encoding is determined from the OS locale settings. If standard input or standard output is not a terminal, the default value for psql's client encoding follows the client_encoding specified in the server's postgresql.conf file. The client encoding can be changed by modifying the PGCLIENTENCODING environment variable.

Platform: Windows, Linux  |  Version: All versions

The String type data in the .NET Framework is internally held as UTF16. Therefore, when data converted to SJIS on the server side according to client_encoding was subsequently converted from SJIS to UTF16 on the client side, there were no corresponding character conversion rules in the .NET Framework.
Npgsql returns string type data as .NET Framework string objects, so it converts the received byte sequence to UTF16 according to the encoding set in the Encoding parameter.
If ClientEncoding parameter, PGCLIENTENCODING environment variable, and Encoding parameter are set to SJIS, data is converted from UTF8 to SJIS on the server side and then sent to the client. When Npgsql receives this data and tries to convert it from SJIS to UTF16, characters for which no conversion rules are defined in the .NET Framework cause an error.
Note that if the ClientEncoding parameter, PGCLIENTENCODING environment variable, and Encoding parameter are set to UTF8, Npgsql interprets the byte sequence received from the server as UTF8 and performs code conversion from UTF8 to UTF16. Since both UTF8 and UTF16 are Unicode encoding schemes, no conversion errors occur.
Therefore, when using Npgsql, it is generally recommended to set ClientEncoding and the PGCLIENTENCODING environment variable to their default value of UTF8.
If client_encoding is specified in the server's postgresql.conf file, it affects the default value of client_encoding for all applications connecting to the server. However, for applications using Npgsql only, the impact can be localized by specifying UTF8 for the ClientEncoding parameter in the connection string, etc.

Platform: Windows, Linux  |  Version: All versions

If there are many subtransactions created by SAVEPOINT commands, etc., within a single transaction, simultaneous execution of multiple SQL commands may have resulted in contention for reading subtransaction information.
In PostgreSQL, when more than 64 subtransactions exist, visibility of a row is determined by expanding disk-resident subtransaction information into a cache area. An exclusive lock is acquired during this expansion, which may cause other transactions attempting to concurrently read subtransaction information to enter a waiting state. The longer a long transaction remains, the more subtransaction information is accessed, increasing the likelihood of contention and associated wait time occurring.

To prevent long transactions, either COMMIT at an appropriate time or reduce the number of subtransactions per transaction to 64 or less.

Platform: Windows, Linux  |  Version: All versions

This may be caused because the archive log storage directory specified in archive_command in postgresql.conf does not exist.
The pg_stop_backup command waits for logs output until command execution to be saved as archive logs.
Therefore, if the archive log storage directory does not exist and archive logs cannot be saved, the command will remain in a waiting state until that condition is resolved.

Check if the archive log storage directory specified in archive_command in postgresql.conf exists, or if there is an error in the specified directory name.
If the specified directory does not exist, create it.

Platform: Windows, Linux  |  Version: All versions

It may be because the application is not disconnecting from the database, leaving unnecessary connections. Use the pg_stat_activity view to check the status of connected connections. Disconnect unnecessary connections using the pg_terminate_backend function in Fujitsu Enterprise Postgres. Also, check the application and add a process to disconnect from the database to the application.

If a process to disconnect from the database is already implemented, review the maximum number of concurrent connections specified in the max_connections parameter of postgresql.conf.

For details on disconnecting from the database, refer to the PostgreSQL Documentation > Part IV - Client Interfaces > Chapter 34 - ECPG — Embedded SQL in C > 34.2 - Managing Database Connections(it provides a detailed explanation for Embedded SQL in C; if other interfaces are used, refer to the manual for the corresponding programming language). For details on the max_connections parameter, refer to PostgreSQL Documentation > Part III. Server Administration > Chapter 19. Server Configuration > 19.3. Connections and Authentication > 19.3.1. Connection Settings

Platform: Windows, Linux |  Version: All versions

If Fujitsu Enterprise Postgres terminated abnormally and messages containing error codes such as 0xC000009A, 0xC00000FD, 0xC000012D, 1450, 1455 were output, it is possible that Fujitsu Enterprise Postgres was unable to operate due to insufficient memory.

LOG: server process (PID xxx) was terminated by exception 0xC000009A

LOG: server process (PID xxx) was terminated by exception 0xC00000FD

LOG: autovacuum launcher process (PID xxx) was terminated by exception 0xC000012D

LOG: CreateProcess call failed: A blocking operation was interrupted by a call to WSACancelBlockingCall.(error code 1450)

LOG: CreateProcess call failed: No error (error code 1450)

LOG: CreateProcess call failed: A blocking operation was interrupted by a call to WSACancelBlockingCall.(error code 1455)

FATAL: could not reattach to shared memory (key=xxx, addr=xxx): error code 1455

Estimate the memory usage of products running on the server, including Fujitsu Enterprise Postgres, and check if the installed memory is adequate. If it is insufficient but cannot be increased, tune to reduce memory usage, such as decreasing the number of connections to the database. For details, refer to Fujitsu Enterprise Postgres Installation and Setup Guide for Server > Appendix F - Memory Estimation

Platform: Windows  |  Version: All versions

The database server startup process did not complete within the maximum number of seconds to wait for startup to complete due to crash recovery (automatic recovery to maintain data integrity) operating.

Specify a larger value for the maximum number of seconds to wait for startup to complete using the -t option of the pg_ctl start command or the PGCTLTIMEOUT environment variable. If the -t option of the pg_ctl start command or the PGCTLTIMEOUT environment variable is not specified, the maximum number of seconds to wait for startup to complete is 60 seconds. For details, refer to PostgreSQL Documentation > VI. Reference > PostgreSQL Server Applications > pg_ctl.

Platform: Windows, Linux  |  Version: All versions

The backup directory specified in the backup_destination and archive_command parameters of the postgresql.conf file are different. Stop the database server and correct the backup directory specified in the backup_destination and archive_command parameters of the postgresql.conf file, then restart the database server.

The values to be specified for the backup_destination and archive_command parameters of the postgresql.conf file are as follows.

• backup_destination parameter: Name of the backup data storage directory.
• archive_command parameter: For Linux: installation_directory/bin/pgx_walcopy.cmd "%p" "backup_data_storage_directory/archived_wal/%f". For Windows: cmd /c ""installation_directory\\bin\\pgx_walcopy.cmd" "%p" "backup_data_storage_directory\\archived_wal\\%f""

For details, refer to Fujitsu Enterprise Postgres Documentation Operation Guide > Chapter 3: Database backup > 3.2 Backup Methods > 3.2.2 When using server commands

Platform: Windows, Linux  |  Version: All versions

The transaction ID is approaching its wraparound limit. To avoid this, perform vacuum processing manually or by appropriately configuring autovacuum settings (postgresql.conf) and performing vacuum processing periodically.

However, if the cause is the presence of long transactions, vacuum processing will not be performed on locations where long transactions hold conflicting locks. Therefore, it may be necessary to consider monitoring long transactions, for example, by periodically checking the pg_stat_activity view.

Platform: Windows  |  Version: All versions

Instance information created before uninstallation still remains. You can either create an instance with a port number different from the one used by the instance created before uninstallation, within the range 1024 to 49151, or delete instance information created before uninstallation, and then create the instance again.

To delete instance information created before uninstallation:

• Ensure that the data directory, backup directory, and transaction log directory do not exist
• Comment out the lines with the corresponding port numbers in the services file (Windows services file).
  Display the Windows service list (for example, in Computer Management, select Services and Applications > Services).
  If a service for the instance created before uninstallation exists in the service list, execute sc delete service name in the command prompt to delete that service.

For details, refer to Fujitsu Enterprise Postgres Installation and Setup Guide for Server Edition > Chapter 4 - Setup.

Platform: Windows  |  Version: All versions

An IP address matching 127.0.0.1 is not specified for the hostname in the password file pgpass.conf. Since the pgx_dmpall command connects to the database by specifying 127.0.0.1, specify an IP address matching 127.0.0.1 for the hostname in the pgpass.conf and re-execute the command.

For details, refer to Fujitsu Enterprise Postgres Documentation Reference Guide > Chapter 3 Server Commands > 3.2 pgx_dumpall

Platform: Windows  |  Version: All versions

It may be that constraint exclusion is not working because the WHERE clause of the executed SQL statement does not contain a constant or parameter value. Check that the constraint_exclusion parameter is set to partition or on, and then specify the WHERE clause with a constant or parameter value to narrow down the partitions.

For details, refer to PostgreSQL Documentation > II. The SQL Language > 5. Data Definition > 5.12 Partitioning > 5.12.5 Partitioning and Constraint Exclusion

Platform: Windows, Linux  |  Version: All versions

The pg_restore command restores data using SQL commands, which causes WAL to be generated. Free space can run low due to the ensuing creation of transaction log files, replicated WAL files, and archive log files.

If the backup_destination and archive_mode are configured in postgresql.conf, comment them out before executing the pg_restore command and restart the database instance. This will prevent the creation of replicated WAL files and archive log files. After the pg_restore command completes, revert the commented-out parameter settings and restart the database instance. For details, refer to Fujitsu Enterprise Postgres Operation Guide > Appendix A Parameters > backup_destination and PostgreSQL Documentation > III. Server Administration > 19. Server Configuration > 19.5 Write Ahead Log > archive_mode

Platform: Windows, Linux  |  Version: All versions

The application of checkpoints may be taking a long time during the shutdown process. The default timeout value for shutdown (when executing pg_ctl) is 60 seconds. If it takes longer than that, the pg_ctl command will error out, but the shutdown process will continue in the background and complete without issues.

To wait for a longer period, specify a larger value for the "maximum number of seconds to wait for shutdown to complete" using the -t option of the pg_ctl stop command or the PGCTLTIMEOUT environment variable. For details, refer to PostgreSQL Documentation > VI. Reference > PostgreSQL Server Applications > pg_ctl

Platform: Windows, Linux  |  Version: All versions

This may have been caused by the WAL application process in the standby server's startup process, which is waiting for read-only SQL statements to complete. On a standby server, conflicts can occur between queries to the standby server and WAL application for certain operations (e.g., table exclusive locks, DROP DATABASE, VACUUM) sent from the primary server. If such conflicts occur, WAL application may enter a waiting state, preventing WAL files from being deleted.

Consider stopping long-running read-only SQL queries executing on the standby server. Also, consider setting the max_standby_streaming_delay parameter to 1 or greater. If the parameter is set and read-only SQL queries run longer than the specified time, they may return error "FATAL: 40000: terminating connection due to conflict with recovery" error. Therefore, take into account the execution time of read-only SQL queries when setting this parameter. For details, refer to PostgreSQL Documentation > III. Server Administration > 19. Server Configuration > 19.6 Replication > max_standby_streaming_delay

Platform: Windows, Linux  |  Version: All versions

This may have been caused by long-running transactions that existed prior to the start of the pg_repack command's table reorganization. The -T option of pg_repack specifies the waiting time for other transactions to be canceled when a lock conflict occurs on the target table. It has no effect when waiting for long-running transactions to complete.

pg_repack table reorganization creates a temporary work table for the target table. Triggers are set on the target table, and update processing during reorganization is recorded in an update log table. After reorganization is complete, the differential information is applied to the work table, and switched with the target table. When applying the differential information to the work table, the process waits for all transactions that started before that to complete. There is no option to set a timeout for this transaction completion wait. To avoid this, ensure that long transactions do not occur during pg_repack operations (for example, COMMIT or ROLLBACK transactions that are running during pg_repack as soon as necessary processing is complete). Also, it is recommended to schedule pg_repack and batch processes (which tend to be long transactions) at different times.

Platform: Linux  |  Version: All versions

If you are using Pgpool-II's failover function, failover may occur even due to temporary network issues depending on parameter settings. If the failover_on_backend_error parameter in pgpool.conf is set to its default value or on, Pgpool-II will automatically execute failover if it detects a communication error in any established connection between the database and Pgpool-II.

In this case, retries cannot be configured for the detected error, so failover will occur even for network abnormalities that are very brief and do not warrant switching databases. Especially in cloud environments, connections in an idle state may be automatically terminated during live migration, etc. If an idle connection in Pgpool-II's connection pooling is terminated by this mechanism, Pgpool-II will detect an abnormality when it attempts to use that connection, leading to failover occurring at a different time than when the connection was actually terminated.

To avoid this, consider setting the failover_on_backend_error parameter in pgpool.conf to off and enabling the health check function. For details, refer to pgpool-II Documentation > II. Server Administration > 5. Server Configuration > 5.9 Health Check

Platform: Linux  |  Version: All versions

This may have been caused by pg_stat_statements. It appends SQL statement information to an external file pg_stat_tmp/pgss_query_texts.stat. When the external file grows large, a process to delete unnecessary data runs to reduce its size.

During this process, disk I/O is involved, and an exclusive lock is acquired on pg_stat_statements, which may cause other concurrent transactions to wait for locks, leading to degraded response times. The timing of unnecessary data deletion is determined by the number of items specified in the pg_stat_statements.max parameter and the average length of executed SQL statements.

Consider reducing the pg_stat_statements.max parameter to shorten the time required for a single unnecessary data deletion process. Alternatively, execute the pg_stat_statements_reset() function periodically to initialize the external file. For details, refer to PostgreSQL Documentation > Part VIII. Appendixes > Appendix F. Additional Supplied Modules and Extensions > F.32. pg_stat_statements

Platform: Windows, Linux  |  Version: All versions

Delete the folders C:\Users[login username]\AppData\Roaming\pgAdmin and C:\Users[login username]\AppData\Roaming\pgAdmin, and then start pgAdmin4.

If that does not solve the issue, disable proxy settings for 127.0.0.1 (localhost) communication, because otherwise pgAdmin4 mail fail to start. If a proxy is enabled for localhost communication in your environment, disable it or add NO_PROXY=127.0.0.1,localhost to your environment variables and then try starting pgAdmin4.

Platform: Windows  |  Version: All versions

If the parameter restore_command was set on the standby instance, its execution may have taken a long time. If restore_command is set, when the standby instance receives a promotion request, restore_command is executed multiple times, and the promotion process waits for it to complete. In this situation, if restore_command is a copy command involving network communication, such as an scp command, and the network to the destination is unavailable, the promotion process may take a long time due to waiting for the copy command to return. As a result, the error pg_ctl: server did not promote in time may be displayed, and the promotion process may time out.

To avoid this, when setting a copy command involving network communication, such as scp, for restore_command, set a timeout for the copy command so that the process completes within the waiting time specified for the pg_ctl promote command. For example, for the scp command, the -o "ConnectTimeout timeout" option can be used. In case of network unavailability, restore_command may run about 5 times after receiving a promotion request. Therefore, the timeout value should be set with some margin against the waiting time (default: 60 seconds) specified for the pg_ctl promote command.

For details, refer to PostgreSQL Documentation > Part III. Server Administration > Chapter 19. Server Configuration > 19.5. Write Ahead Log > 19.5.5. Archive Recovery > restore_command

Platform: Windows, Linux  |  Version: All versions

The cause is the presence of a large amount of old updated and deleted data. Fujitsu Enterprise Postgres adopts an append-only architecture to minimize contention due to locks when writing table data. Therefore, when UPDATE and DELETE statements are executed, old updated and deleted data continues to be retained in the table.

To reclaim old updated and deleted data, enable autovacuum or regularly execute VACUUM and ANALYZE commands manually. However, the VACUUM command may acquire exclusive locks and generate a large amount of I/O traffic, potentially degrading the performance of other active sessions. When executing the VACUUM command, set related parameters to mitigate its impact on performance. For details, refer to the PostgreSQL Documentation > Part III - Server Administration > Chapter 24 - Routine Database Maintenance Tasks > 24.1 - Routine Vacuuming.

Platform: Linux  |  Version: All versions

You can recover to a specified date and time using server commands, but not using WebAdmin. For details, refer to the Fujitsu Enterprise Postgres Operation Guide > Chapter 5 - Protecting Storage Data with Transparent Data Encryption > 5.7 - Backing Up and Restoring/Recovering the Database and PostgreSQL Documentation > Part III - Server Administration > Chapter 25 - Backup and Restore > 25.3 - Continuous Archiving and Point-in-Time Recovery (PITR).

Platform: Linux  |  Version: All versions

No, you should not delete them. Files in the backup directory are managed by Fujitsu Enterprise Postgres. Updating or deleting them may prevent Fujitsu Enterprise Postgres from starting, or prevent database backups and recovery.

Deleting .backup files may cause the Fujitsu Enterprise Postgres pgx_dmpall command error could not open file "x://xxxxx/archived_wal/xxxx.backup": No such file or directory.

Platform: Linux  |  Version: All versions

The WebAdmin setup was not executed after applying the urgent patch. Refer to the [Notes] section in the urgent patch information file and execute WebAdmin setup. For details on setup, refer to the Fujitsu Enterprise Postgres Installation and Setup Guide for Server Edition > Appendix B - Setting Up and Removing WebAdmin > B.1 - Setting Up WebAdmin > B.1.1 - Setting Up WebAdmin.

Platform: Linux  |  Version: All versions

No, you should not delete them. The transaction log directory and its files are managed by Fujitsu Enterprise Postgres, so do not delete or update them, otherwise Fujitsu Enterprise Postgres may not be able to start or perform database recovery. For disk space issues, refer to the Fujitsu Enterprise Postgres Operation Guide > Chapter 18 - Actions when an Error Occurs > 18.8 Actions in Response to Insufficient Space on the Transaction Log Storage Destination, and for the required disk space for the transaction log directory, refer to the Fujitsu Enterprise Postgres Installation and Setup Guide for Server > Appendix E - Estimating Transaction Log Space Requirements.

If files in the transaction log directory are deleted, executing pg_ctl start may cause the error below:

LOG: invalid primary checkpoint record
PANIC: could not locate a valid checkpoint record

Platform: Linux  |  Version: All versions

This indicates that a timeout was detected by the OS/server liveness monitoring (heartbeat) of the database multiplexing operation (Mirroring Controller). If the OS/server is not down, the cause may be temporary network or server load.

Review the liveness monitoring timeout period specified in seconds by the heartbeat_timeout parameter of the database multiplexing operation's server definition file.
For details, refer to the Fujitsu Enterprise Postgres Cluster Operation Guide (Database Multiplexing) > Chapter 2 - Setting Up Database Multiplexing Mode ;> 2.11 Tuning > 2.11.4 - Tuning for Optimization of Degradation Using Abnormality Monitoring and Appendix A: Parameters > A.4 Server Configuration File.

If liveness monitoring times out consecutively for a number of times (specified in the heartbeat_retry parameter + 1), the database multiplexing operation automatically performs a primary server switchover or standby server detachment. The MCA00019 error is output for each liveness monitoring timeout detected

Platform: Linux  |  Version: All versions

You can verify which tablespaces are encrypted and their encryption algorithm using the pgx_tablespaces system view: SELECT spcname, spcencalgo FROM pg_tablespace ts, pgx_tablespaces tsx WHERE ts.oid = tsx.spctablespace;.

Platform: Linux  |  Version: All versions

Encryption using Transparent Data Encryption is applied at the tablespace level. This means that data such as tables and indexes created in the specified tablespace, the WAL, backup files, and archive logs will be automatically encrypted.

The data and index in the encrypted tablespace along with the associated WAL files can be backed up by taking a physical backup using the pgx_dmpall or pg_basebackup command. It is important to back up the keystore.ks file so that encrypted data can be restored with a keystore and passphrase. If there is any tablespace which is not encrypted, then it is backed up as unencrypted.

Note that a logical backup taken by pg_dump, pg_dumpall, or COPY command is not encrypted. This is because a logical backup is taken through SQL interface (like a client executing any other select statement), so encrypted data are decrypted before writing to a backup file.

Platform: Linux  |  Version: All versions

If you want to mask the first 12 digits of a credit card number, you can apply partial masking. There are 3 different types of Data Masking supported that can be applied using masking policies, which include:

• Full masking, where a whole column value can be obfuscated with alternate values. For example, values in a numeric type of column are replaced with ‘0’ and values in a character type of column are replaced with a space.
• Partial masking, which allows masking part of a string - for example, the first 12 digits of a credit card number can be replaced with ‘*’.
• Regular expression masking is flexible and allows you to define masking by using regular expressions, which is useful for unstructured types like XML or JSON (ability to mask a single element). For example, for strings with variable length such as email address, characters preceding ‘@’ can be replaced with ‘*’.

You can specify whether to apply a masking policy using a function - if it returns is true, then masking will be applied. This approach also gives the flexibility to selectively mask data to specific users.

Platform: Linux  |  Version: All versions