From 7f8d54f9c897abdb173fad3865abbbb049ccf74b Mon Sep 17 00:00:00 2001 From: himmel Date: Tue, 25 Nov 2025 19:21:38 +0800 Subject: [PATCH 1/2] Update release notes for v5.0 --- CN/modules/ROOT/pages/v5.0/1.adoc | 7 ++-- EN/modules/ROOT/pages/v5.0/1.adoc | 5 +-- EN/modules/ROOT/pages/v5.0/9.adoc | 68 +++++++++++++++---------------- 3 files changed, 39 insertions(+), 41 deletions(-) diff --git a/CN/modules/ROOT/pages/v5.0/1.adoc b/CN/modules/ROOT/pages/v5.0/1.adoc index 28044660..faa6c042 100644 --- a/CN/modules/ROOT/pages/v5.0/1.adoc +++ b/CN/modules/ROOT/pages/v5.0/1.adoc @@ -6,7 +6,7 @@ [*发布日期：2025 年 11 月 25 日*] -IvorySQL 5.0 基于 PostgreSQL 18.0，带来更强的 Oracle 兼容能力、PL/iSQL 增强以及全新的全球化特性，同时对打包、自动化和工具链进行全面更新。 +IvorySQL 5.0 基于 PostgreSQL 18.0，在 Oracle 兼容性、生态组件集成和云原生方面实现重大升级，在易用性方面提供主流全平台介质包和流畅的在线体验。 有关完整更新列表，请访问我们的 https://docs.ivorysql.org/[文档站点]。 == 增强内容 @@ -169,12 +169,10 @@ IvorySQL 的主要代码仓库： * ccwxl * Cédric Villemain -* elodiefb * Grant Zhou * Imran Zaheer * luss * Martin Gerhardy -* msdnchina * omstack * otegami * rophy @@ -185,6 +183,7 @@ IvorySQL 的主要代码仓库： * 崇鹏豪 * 高雪玉 * 矫顺田 +* 付贝 * 类延良 * 李苑 * 梁翔宇 @@ -203,4 +202,4 @@ IvorySQL 的主要代码仓库： * 严少安 * 杨世华 * 赵法威 -* 张哲 \ No newline at end of file +* 张哲 diff --git a/EN/modules/ROOT/pages/v5.0/1.adoc b/EN/modules/ROOT/pages/v5.0/1.adoc index b9e5c7bf..011ce9fe 100644 --- a/EN/modules/ROOT/pages/v5.0/1.adoc +++ b/EN/modules/ROOT/pages/v5.0/1.adoc @@ -168,10 +168,10 @@ IvorySQL's development is maintained across four main repositories: The following individuals (in alphabetical order) have contributed to this release as patch authors, committers, reviewers, testers, or reporters of issues. +* Bei Fu * Carlos Chong * ccwxl * Cédric Villemain -* elodiefb * Fawei Zhao * Ge Sui * Grant Zhou @@ -180,7 +180,6 @@ The following individuals (in alphabetical order) have contributed to this relea * Jiaoshun Tian * luss * Martin Gerhardy -* msdnchina * omstack * otegami * Ruike Sun @@ -204,4 +203,4 @@ The following individuals (in alphabetical order) have contributed to this relea * Zhe Zhang * Zheng Tao * Zhenhao Pan -* Zhuoyan Shi \ No newline at end of file +* Zhuoyan Shi diff --git a/EN/modules/ROOT/pages/v5.0/9.adoc b/EN/modules/ROOT/pages/v5.0/9.adoc index 43b2b6e9..d4b420c6 100644 --- a/EN/modules/ROOT/pages/v5.0/9.adoc +++ b/EN/modules/ROOT/pages/v5.0/9.adoc @@ -13,40 +13,40 @@ When specified on the command line, user and database names have their case pres |=== | category | Tool name | Description -| Client Applications | clusterdb | clusterdb is a utility for reclustering tables in a IvorySQL database. It finds tables that have previously been clustered, and clusters them again on the same index that was last used. Tables that have never been clustered are not affected.clusterdb is a wrapper around the SQL command http://www.postgresql.org/docs/17/sql-cluster.html[CLUSTER]. There is no effective difference between clustering databases via this utility and via other methods for accessing the server. -| | createdb | createdb creates a new IvorySQL database.Normally, the database user who executes this command becomes the owner of the new database. However, a different owner can be specified via the -O option, if the executing user has appropriate privileges.createdb is a wrapper around the SQL command http://www.postgresql.org/docs/17/sql-createdatabase.html[`CREATE DATABASE`]. There is no effective difference between creating databases via this utility and via other methods for accessing the server. -| | createuser | createuser creates a new IvorySQL user (or more precisely, a role). Only superusers and users with `CREATEROLE` privilege can create new users, so createuser must be invoked by someone who can connect as a superuser or a user with `CREATEROLE` privilege. createuser is a wrapper around the SQL command http://www.postgresql.org/docs/17/sql-createrole.html[`CREATE ROLE`]. There is no effective difference between creating users via this utility and via other methods for accessing the server. -| | dropdb | dropdb destroys an existing IvorySQL database. The user who executes this command must be a database superuser or the owner of the database.dropdb is a wrapper around the SQL command http://www.postgresql.org/docs/17/sql-dropdatabase.html[`DROP DATABASE`]. There is no effective difference between dropping databases via this utility and via other methods for accessing the server. -| | dropuser | dropuser removes an existing IvorySQL user. Only superusers and users with the `CREATEROLE` privilege can remove IvorySQL users. (To remove a superuser, you must yourself be a superuser.)dropuser is a wrapper around the SQL command http://www.postgresql.org/docs/17/sql-droprole.html[`DROP ROLE`]. There is no effective difference between dropping users via this utility and via other methods for accessing the server. -| | ecpg | `ecpg` is the embedded SQL preprocessor for C programs. It converts C programs with embedded SQL statements to normal C code by replacing the SQL invocations with special function calls. The output files can then be processed with any C compiler tool chain.`ecpg` will convert each input file given on the command line to the corresponding C output file. If an input file name does not have any extension, `.pgc` is assumed. The file's extension will be replaced by `.c` to construct the output file name. But the output file name can be overridden using the `-o` option.If an input file name is just `-`, `ecpg` reads the program from standard input (and writes to standard output, unless that is overridden with `-o`).This reference page does not describe the embedded SQL language. -| | pg_amcheck | pg_amcheck supports running http://www.postgresql.org/docs/17/amcheck.html[amcheck]'s corruption checking functions against one or more databases, with options to select which schemas, tables and indexes to check, which kinds of checking to perform, and whether to perform the checks in parallel, and if so, the number of parallel connections to establish and use. -| | pg_basebackup | pg_basebackup is used to take a base backup of a running IvorySQL database cluster. The backup is taken without affecting other clients of the database, and can be used both for point-in-time recovery and as the starting point for a log-shipping or streaming-replication standby server.pg_basebackup makes an exact copy of the database cluster's files, while making sure the server is put into and out of backup mode automatically. Backups are always taken of the entire database cluster; it is not possible to back up individual databases or database objects. For selective backups, another tool such as http://www.postgresql.org/docs/17/app-pgdump.html[pg_dump] must be used.The backup is made over a regular IvorySQL connection that uses the replication protocol. The connection must be made with a user ID that has `REPLICATION` permissions or is a superuser, and http://www.postgresql.org/docs/17/auth-pg-hba-conf.html[`pg_hba.conf`] must permit the replication connection. The server must also be configured with http://www.postgresql.org/docs/17/runtime-config-replication.html#GUC-MAX-WAL-SENDERS[max_wal_senders] set high enough to provide at least one walsender for the backup plus one for WAL streaming (if used).There can be multiple `pg_basebackup`s running at the same time, but it is usually better from a performance point of view to take only one backup, and copy the result.pg_basebackup can make a base backup from not only a primary server but also a standby. To take a backup from a standby, set up the standby so that it can accept replication connections (that is, set `max_wal_senders` and http://www.postgresql.org/docs/17/runtime-config-replication.html#GUC-HOT-STANDBY[hot_standby], and configure its `pg_hba.conf` appropriately). You will also need to enable http://www.postgresql.org/docs/17/runtime-config-wal.html#GUC-FULL-PAGE-WRITES[full_page_writes] on the primary. -| | pgbench | pgbench is a simple program for running benchmark tests on IvorySQL. It runs the same sequence of SQL commands over and over, possibly in multiple concurrent database sessions, and then calculates the average transaction rate (transactions per second). By default, pgbench tests a scenario that is loosely based on TPC-B, involving five `SELECT`, `UPDATE`, and `INSERT` commands per transaction. However, it is easy to test other cases by writing your own transaction script files. -| | pg_config | The pg_config utility prints configuration parameters of the currently installed version of IvorySQL. It is intended, for example, to be used by software packages that want to interface to IvorySQL to facilitate finding the required header files and libraries. -| | pg_dump | pg_dump is a utility for backing up a IvorySQL database. It makes consistent backups even if the database is being used concurrently. pg_dump does not block other users accessing the database (readers or writers).pg_dump only dumps a single database. To back up an entire cluster, or to back up global objects that are common to all databases in a cluster (such as roles and tablespaces), use http://www.postgresql.org/docs/17/app-pg-dumpall.html[pg_dumpall]. Dumps can be output in script or archive file formats. Script dumps are plain-text files containing the SQL commands required to reconstruct the database to the state it was in at the time it was saved. To restore from such a script, feed it to http://www.postgresql.org/docs/17/app-psql.html[psql]. Script files can be used to reconstruct the database even on other machines and other architectures; with some modifications, even on other SQL database products.The alternative archive file formats must be used with http://www.postgresql.org/docs/17/app-pgrestore.html[pg_restore] to rebuild the database. They allow pg_restore to be selective about what is restored, or even to reorder the items prior to being restored. The archive file formats are designed to be portable across architectures.When used with one of the archive file formats and combined with pg_restore, pg_dump provides a flexible archival and transfer mechanism. pg_dump can be used to backup an entire database, then pg_restore can be used to examine the archive and/or select which parts of the database are to be restored. The most flexible output file formats are the “custom” format ( `-Fc` ) and the “directory” format ( `-Fd` ). They allow for selection and reordering of all archived items, support parallel restoration, and are compressed by default. The “directory” format is the only format that supports parallel dumps.While running pg_dump, one should examine the output for any warnings (printed on standard error), especially in light of the limitations listed below. -| | pg_dumpall | pg_dumpall is a utility for writing out (“dumping”) all IvorySQL databases of a cluster into one script file. The script file contains SQL commands that can be used as input to http://www.postgresql.org/docs/17/app-psql.html[psql] to restore the databases. It does this by calling http://www.postgresql.org/docs/17/app-pgdump.html[pg_dump] for each database in the cluster. pg_dumpall also dumps global objects that are common to all databases, namely database roles, tablespaces, and privilege grants for configuration parameters. (pg_dump does not save these objects.)Since pg_dumpall reads tables from all databases you will most likely have to connect as a database superuser in order to produce a complete dump. Also you will need superuser privileges to execute the saved script in order to be allowed to add roles and create databases.The SQL script will be written to the standard output. Use the `-f`/`--file` option or shell operators to redirect it into a file.pg_dumpall needs to connect several times to the IvorySQL server (once per database). If you use password authentication it will ask for a password each time. It is convenient to have a `~/.pgpass` file in such cases. -| | pg_isready | pg_isready is a utility for checking the connection status of a IvorySQL database server. The exit status specifies the result of the connection check. -| | pg_receivewal | pg_receivewal is used to stream the write-ahead log from a running IvorySQL cluster. The write-ahead log is streamed using the streaming replication protocol, and is written to a local directory of files. This directory can be used as the archive location for doing a restore using point-in-time recovery.pg_receivewal streams the write-ahead log in real time as it's being generated on the server, and does not wait for segments to complete like http://www.postgresql.org/docs/17/runtime-config-wal.html#GUC-ARCHIVE-COMMAND[archive_command] does. For this reason, it is not necessary to set http://www.postgresql.org/docs/17/runtime-config-wal.html#GUC-ARCHIVE-TIMEOUT[archive_timeout] when using pg_receivewal.Unlike the WAL receiver of a IvorySQL standby server, pg_receivewal by default flushes WAL data only when a WAL file is closed. The option `--synchronous` must be specified to flush WAL data in real time. Since pg_receivewal does not apply WAL, you should not allow it to become a synchronous standby when http://www.postgresql.org/docs/17/runtime-config-wal.html#GUC-SYNCHRONOUS-COMMIT[synchronous_commit] equals `remote_apply`. If it does, it will appear to be a standby that never catches up, and will cause transaction commits to block. To avoid this, you should either configure an appropriate value for http://www.postgresql.org/docs/17/runtime-config-replication.html#GUC-SYNCHRONOUS-STANDBY-NAMES[synchronous_standby_names], or specify `application_name` for pg_receivewal that does not match it, or change the value of `synchronous_commit` to something other than `remote_apply`.The write-ahead log is streamed over a regular IvorySQL connection and uses the replication protocol. The connection must be made with a user having `REPLICATION` permissions or a superuser, and `pg_hba.conf` must permit the replication connection. The server must also be configured with http://www.postgresql.org/docs/17/runtime-config-replication.html#GUC-MAX-WAL-SENDERS[max_wal_senders] set high enough to leave at least one session available for the stream. -| | pg_recvlogical | `pg_recvlogical` controls logical decoding replication slots and streams data from such replication slots.It creates a replication-mode connection, so it is subject to the same constraints as http://www.postgresql.org/docs/17/app-pgreceivewal.html[pg_receivewal], plus those for logical replication .`pg_recvlogical` has no equivalent to the logical decoding SQL interface's peek and get modes. It sends replay confirmations for data lazily as it receives it and on clean exit. To examine pending data on a slot without consuming it, use http://www.postgresql.org/docs/17/functions-admin.html#FUNCTIONS-REPLICATION[`pg_logical_slot_peek_changes`]. -| | pg_restore | pg_restore is a utility for restoring a IvorySQL database from an archive created by http://www.postgresql.org/docs/17/app-pgdump.html[pg_dump] in one of the non-plain-text formats. It will issue the commands necessary to reconstruct the database to the state it was in at the time it was saved. The archive files also allow pg_restore to be selective about what is restored, or even to reorder the items prior to being restored. The archive files are designed to be portable across architectures.pg_restore can operate in two modes. If a database name is specified, pg_restore connects to that database and restores archive contents directly into the database. Otherwise, a script containing the SQL commands necessary to rebuild the database is created and written to a file or standard output. This script output is equivalent to the plain text output format of pg_dump. Some of the options controlling the output are therefore analogous to pg_dump options.Obviously, pg_restore cannot restore information that is not present in the archive file. For instance, if the archive was made using the “dump data as `INSERT` commands” option, pg_restore will not be able to load the data using `COPY` statements. -| | pg_verifybackup | pg_verifybackup is used to check the integrity of a database cluster backup taken using `pg_basebackup` against a `backup_manifest` generated by the server at the time of the backup. The backup must be stored in the "plain" format; a "tar" format backup can be checked after extracting it.It is important to note that the validation which is performed by pg_verifybackup does not and cannot include every check which will be performed by a running server when attempting to make use of the backup. Even if you use this tool, you should still perform test restores and verify that the resulting databases work as expected and that they appear to contain the correct data. However, pg_verifybackup can detect many problems that commonly occur due to storage problems or user error.Backup verification proceeds in four stages. First, `pg_verifybackup` reads the `backup_manifest` file. If that file does not exist, cannot be read, is malformed, or fails verification against its own internal checksum, `pg_verifybackup` will terminate with a fatal error. -| | psql | psql is a terminal-based front-end to IvorySQL. It enables you to type in queries interactively, issue them to IvorySQL, and see the query results. Alternatively, input can be from a file or from command line arguments. In addition, psql provides a number of meta-commands and various shell-like features to facilitate writing scripts and automating a wide variety of tasks. -| | reindexdb | reindexdb is a utility for rebuilding indexes in a IvorySQL database.reindexdb is a wrapper around the SQL command http://www.postgresql.org/docs/17/sql-reindex.html[`REINDEX`]. There is no effective difference between reindexing databases via this utility and via other methods for accessing the server. -| | vacuumdb | vacuumdb is a utility for cleaning a IvorySQL database. vacuumdb will also generate internal statistics used by the IvorySQL query optimizer. -| Server Applications | initdb(1) | `initdb` creates a new IvorySQL database cluster. A database cluster is a collection of databases that are managed by a single server instance.Creating a database cluster consists of creating the directories in which the database data will live, generating the shared catalog tables (tables that belong to the whole cluster rather than to any particular database), and creating the `postgres`, `template1`, and `template0` databases. The `postgres` database is a default database meant for use by users, utilities and third party applications. `template1` and `template0` are meant as source databases to be copied by later `CREATE DATABASE` commands. `template0` should never be modified, but you can add objects to `template1`, which by default will be copied into databases created later.Although `initdb` will attempt to create the specified data directory, it might not have permission if the parent directory of the desired data directory is root-owned. To initialize in such a setup, create an empty data directory as root, then use `chown` to assign ownership of that directory to the database user account, then `su` to become the database user to run `initdb`. -| Server Applications | initdb(2) | `initdb` must be run as the user that will own the server process, because the server needs to have access to the files and directories that `initdb` creates. Since the server cannot be run as root, you must not run `initdb` as root either. (It will in fact refuse to do so.)For security reasons the new cluster created by `initdb` will only be accessible by the cluster owner by default. The `--allow-group-access` option allows any user in the same group as the cluster owner to read files in the cluster. This is useful for performing backups as a non-privileged user.`initdb` initializes the database cluster's default locale and character set encoding. These can also be set separately for each database when it is created. `initdb` determines those settings for the template databases, which will serve as the default for all other databases. By default, `initdb` uses the locale provider `libc`, takes the locale settings from the environment, and determines the encoding from the locale settings. This is almost always sufficient, unless there are special requirements.To choose a different locale for the cluster, use the option `--locale`. There are also individual options `--lc-*` (see below) to set values for the individual locale categories. Note that inconsistent settings for different locale categories can give nonsensical results, so this should be used with care.Alternatively, the ICU library can be used to provide locale services. (Again, this only sets the default for subsequently created databases.) To select this option, specify `--locale-provider=icu`. To choose the specific ICU locale ID to apply, use the option `--icu-locale`. Note that for implementation reasons and to support legacy code, `initdb` will still select and initialize libc locale settings when the ICU locale provider is used.When `initdb` runs, it will print out the locale settings it has chosen. If you have complex requirements or specified multiple options, it is advisable to check that the result matches what was intended. -| | pg_archivecleanup | pg_archivecleanup is designed to be used as an `archive_cleanup_command` to clean up WAL file archives when running as a standby server .pg_archivecleanup can also be used as a standalone program to clean WAL file archives. -| | pg_checksums | pg_checksums checks, enables or disables data checksums in a IvorySQL cluster. The server must be shut down cleanly before running pg_checksums. When verifying checksums, the exit status is zero if there are no checksum errors, and nonzero if at least one checksum failure is detected. When enabling or disabling checksums, the exit status is nonzero if the operation failed.When verifying checksums, every file in the cluster is scanned. When enabling checksums, each relation file block with a changed checksum is rewritten in-place. Disabling checksums only updates the file `pg_control`. -| | pg_controldata | `pg_controldata` prints information initialized during `initdb`, such as the catalog version. It also shows information about write-ahead logging and checkpoint processing. This information is cluster-wide, and not specific to any one database.This utility can only be run by the user who initialized the cluster because it requires read access to the data directory. You can specify the data directory on the command line, or use the environment variable `PGDATA`. This utility supports the options `-V` and `--version`, which print the pg_controldata version and exit. It also supports options `-?` and `--help`, which output the supported arguments. -| | pg_ctl | pg_ctl is a utility for initializing a IvorySQL database cluster, starting, stopping, or restarting the IvorySQL database server (http://www.postgresql.org/docs/17/app-postgres.html[postgres]), or displaying the status of a running server. Although the server can be started manually, pg_ctl encapsulates tasks such as redirecting log output and properly detaching from the terminal and process group. It also provides convenient options for controlled shutdown. -| | pg_resetwal | `pg_resetwal` clears the write-ahead log (WAL) and optionally resets some other control information stored in the `pg_control` file. This function is sometimes needed if these files have become corrupted. It should be used only as a last resort, when the server will not start due to such corruption.After running this command, it should be possible to start the server, but bear in mind that the database might contain inconsistent data due to partially-committed transactions. You should immediately dump your data, run `initdb`, and restore. After restore, check for inconsistencies and repair as needed.This utility can only be run by the user who installed the server, because it requires read/write access to the data directory. For safety reasons, you must specify the data directory on the command line. `pg_resetwal` does not use the environment variable `PGDATA`.If `pg_resetwal` complains that it cannot determine valid data for `pg_control`, you can force it to proceed anyway by specifying the `-f` (force) option. In this case plausible values will be substituted for the missing data. Most of the fields can be expected to match, but manual assistance might be needed for the next OID, next transaction ID and epoch, next multitransaction ID and offset, and WAL starting location fields. These fields can be set using the options discussed below. If you are not able to determine correct values for all these fields, `-f` can still be used, but the recovered database must be treated with even more suspicion than usual: an immediate dump and restore is imperative. *Do not* execute any data-modifying operations in the database before you dump, as any such action is likely to make the corruption worse. -| | pg_rewind(1) | pg_rewind is a tool for synchronizing a IvorySQL cluster with another copy of the same cluster, after the clusters' timelines have diverged. A typical scenario is to bring an old primary server back online after failover as a standby that follows the new primary.After a successful rewind, the state of the target data directory is analogous to a base backup of the source data directory. Unlike taking a new base backup or using a tool like rsync, pg_rewind does not require comparing or copying unchanged relation blocks in the cluster. Only changed blocks from existing relation files are copied; all other files, including new relation files, configuration files, and WAL segments, are copied in full. As such the rewind operation is significantly faster than other approaches when the database is large and only a small fraction of blocks differ between the clusters.pg_rewind examines the timeline histories of the source and target clusters to determine the point where they diverged, and expects to find WAL in the target cluster's `pg_wal` directory reaching all the way back to the point of divergence. The point of divergence can be found either on the target timeline, the source timeline, or their common ancestor. In the typical failover scenario where the target cluster was shut down soon after the divergence, this is not a problem, but if the target cluster ran for a long time after the divergence, its old WAL files might no longer be present. In this case, you can manually copy them from the WAL archive to the `pg_wal` directory, or run pg_rewind with the `-c` option to automatically retrieve them from the WAL archive. The use of pg_rewind is not limited to failover, e.g., a standby server can be promoted, run some write transactions, and then rewound to become a standby again.After running pg_rewind, WAL replay needs to complete for the data directory to be in a consistent state. -| | pg_rewind(2) | When the target server is started again it will enter archive recovery and replay all WAL generated in the source server from the last checkpoint before the point of divergence. If some of the WAL was no longer available in the source server when pg_rewind was run, and therefore could not be copied by the pg_rewind session, it must be made available when the target server is started. This can be done by creating a `recovery.signal` file in the target data directory and by configuring a suitable http://www.postgresql.org/docs/17/runtime-config-wal.html#GUC-RESTORE-COMMAND[restore_command] in `IvorySQL.conf`.pg_rewind requires that the target server either has the http://www.postgresql.org/docs/17/runtime-config-wal.html#GUC-WAL-LOG-HINTS[wal_log_hints] option enabled in `IvorySQL.conf` or data checksums enabled when the cluster was initialized with initdb. Neither of these are currently on by default. http://www.postgresql.org/docs/17/runtime-config-wal.html#GUC-FULL-PAGE-WRITES[full_page_writes] must also be set to `on`, but is enabled by default. -| | pg_test_fsync | pg_test_fsync is intended to give you a reasonable idea of what the fastest http://www.postgresql.org/docs/17/runtime-config-wal.html#GUC-WAL-SYNC-METHOD[wal_sync_method] is on your specific system, as well as supplying diagnostic information in the event of an identified I/O problem. However, differences shown by pg_test_fsync might not make any significant difference in real database throughput, especially since many database servers are not speed-limited by their write-ahead logs. pg_test_fsync reports average file sync operation time in microseconds for each `wal_sync_method`, which can also be used to inform efforts to optimize the value of http://www.postgresql.org/docs/17/runtime-config-wal.html#GUC-COMMIT-DELAY[commit_delay]. -| | pg_test_timing | pg_test_timing is a tool to measure the timing overhead on your system and confirm that the system time never moves backwards. Systems that are slow to collect timing data can give less accurate `EXPLAIN ANALYZE` results. -| | pg_upgrade | Major IvorySQL releases regularly add new features that often change the layout of the system tables, but the internal data storage format rarely changes. pg_upgrade uses this fact to perform rapid upgrades by creating new system tables and simply reusing the old user data files. If a future major release ever changes the data storage format in a way that makes the old data format unreadable, pg_upgrade will not be usable for such upgrades. (The community will attempt to avoid such situations.)pg_upgrade does its best to make sure the old and new clusters are binary-compatible, e.g., by checking for compatible compile-time settings, including 32/64-bit binaries. It is important that any external modules are also binary compatible, though this cannot be checked by pg_upgrade. -| | pg_waldump | `pg_waldump` displays the write-ahead log (WAL) and is mainly useful for debugging or educational purposes.This utility can only be run by the user who installed the server, because it requires read-only access to the data directory. -| | postgres | `postgres` is the IvorySQL database server. In order for a client application to access a database it connects (over a network or locally) to a running `postgres` instance. The `postgres` instance then starts a separate server process to handle the connection. +| Client Applications | clusterdb | Reclusters the tables that were previously marked as clustered, acting as a wrapper around the SQL http://www.postgresql.org/docs/17/sql-cluster.html[CLUSTER] command. +| | createdb | Creates a new IvorySQL database, optionally specifying owner, encoding, locale or tablespace, just like running http://www.postgresql.org/docs/17/sql-createdatabase.html[`CREATE DATABASE`]. +| | createuser | Creates a new IvorySQL role when run by a superuser or someone with `CREATEROLE`, mirroring http://www.postgresql.org/docs/17/sql-createrole.html[`CREATE ROLE`]. +| | dropdb | Removes an existing database when run by its owner or a superuser, wrapping http://www.postgresql.org/docs/17/sql-dropdatabase.html[`DROP DATABASE`]. +| | dropuser | Deletes an existing role and corresponds to http://www.postgresql.org/docs/17/sql-droprole.html[`DROP ROLE`]; superuser or `CREATEROLE` privileges are required. +| | ecpg | Preprocesses C source files that embed SQL, turning statements into libpq calls so the code can then be compiled with a normal toolchain. +| | pg_amcheck | Runs http://www.postgresql.org/docs/17/amcheck.html[amcheck] routines to validate indexes and heap data, allowing filtered and parallel corruption checks. +| | pg_basebackup | Takes an online base backup over the replication protocol for PITR or standby seeding, copying the entire cluster while managing backup mode automatically. +| | pgbench | Executes customizable benchmark scripts (TPC-B style by default) to measure throughput, concurrency and latency of an IvorySQL instance. +| | pg_config | Prints build-time configuration details (include paths, library directories, version, etc.) for the currently installed IvorySQL binaries. +| | pg_dump | Creates a consistent backup of a single database in plain SQL or archive formats that can later be restored with http://www.postgresql.org/docs/17/app-pgrestore.html[pg_restore]. +| | pg_dumpall | Sequentially dumps every database plus global objects into one SQL script by invoking pg_dump per database. +| | pg_isready | Returns the connection status of a target server so scripts can detect whether IvorySQL is accepting connections. +| | pg_receivewal | Streams WAL segments from a running cluster via the replication protocol and writes them to disk for archiving or downstream recovery. +| | pg_recvlogical | Manages logical-replication slots and streams decoded changes over a replication connection for custom consumers. +| | pg_restore | Replays archives produced by pg_dump (non-plain formats) directly into a database or onto stdout, supporting selective and reordered restores. +| | pg_verifybackup | Validates a plain-format backup created by `pg_basebackup` against its `backup_manifest`, detecting missing or corrupted files before restore. +| | psql | Terminal client that runs SQL interactively or from scripts, providing meta-commands, variables and scripting conveniences. +| | reindexdb | Rebuilds indexes for a database, schema or table set, invoking http://www.postgresql.org/docs/17/sql-reindex.html[`REINDEX`] under the hood. +| | vacuumdb | Automates `VACUUM` (optionally `ANALYZE`) for selected databases or tables to reclaim space and refresh optimizer statistics. +| Server Applications | initdb(1) | Initializes a new database cluster by creating the data directory, catalog tables and default databases (`postgres`, `template1`, `template0`). +| Server Applications | initdb(2) | Must be run as the future cluster owner; controls file permissions plus the default locale, encoding and ICU/libc settings for the cluster. +| | pg_archivecleanup | Cleans archived WAL files, typically via `archive_cleanup_command`, so old segments are removed once they are no longer needed. +| | pg_checksums | Enables, disables or verifies cluster-wide data checksums while the server is stopped, rewriting blocks as needed. +| | pg_controldata | Displays cluster control information (catalog version, checkpoint and WAL status) by reading `pg_control`. +| | pg_ctl | Initializes, starts, stops, restarts or queries the status of the IvorySQL server, handling log redirection and daemonization. +| | pg_resetwal | Resets the WAL and selected control fields after corruption so the server can start, to be followed by a dump and rebuild. +| | pg_rewind(1) | Syncs a diverged cluster with another timeline by copying only the changed blocks since the split, enabling quick re-attachment as a standby. +| | pg_rewind(2) | Requires retained WAL or archive access plus `wal_log_hints` or checksums; after rewinding, recovery replays new WAL before the node can serve. +| | pg_test_fsync | Benchmarks different `wal_sync_method` options to identify the fastest durable fsync strategy on the host OS and storage. +| | pg_test_timing | Measures timer resolution and detects backward time jumps, helping interpret `EXPLAIN ANALYZE` accuracy. +| | pg_upgrade | Reuses existing data files to move between major releases quickly, checking binary compatibility and external module support. +| | pg_waldump | Reads and prints WAL records for debugging or education; requires direct read access to the data directory. +| | postgres | The actual IvorySQL server executable that accepts client connections and forks per-session backend processes. |=== == Client Applications From e087a23fcdc3473844878ac2269b63c370f65eec Mon Sep 17 00:00:00 2001 From: himmel Date: Tue, 25 Nov 2025 19:23:44 +0800 Subject: [PATCH 2/2] update release notes --- CN/modules/ROOT/pages/v5.0/1.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CN/modules/ROOT/pages/v5.0/1.adoc b/CN/modules/ROOT/pages/v5.0/1.adoc index faa6c042..ee339c63 100644 --- a/CN/modules/ROOT/pages/v5.0/1.adoc +++ b/CN/modules/ROOT/pages/v5.0/1.adoc @@ -6,7 +6,7 @@ [*发布日期：2025 年 11 月 25 日*] -IvorySQL 5.0 基于 PostgreSQL 18.0，在 Oracle 兼容性、生态组件集成和云原生方面实现重大升级，在易用性方面提供主流全平台介质包和流畅的在线体验。 +IvorySQL 5.0 基于 PostgreSQL 18.0 全面升级：Oracle 兼容性再突破，生态组件集成再升级，云原生深度支持，配合全平台安装包与在线丝滑体验，让复杂变得简单。 有关完整更新列表，请访问我们的 https://docs.ivorysql.org/[文档站点]。 == 增强内容