Waiting for PG17

PostgreSQL 17 对 COPY 命令做了一个优化，导入数据（COPY FROM）时可以忽略错误字段进而使得 COPY 命令继续导入后面的数据。虽然是很小的一个特性，但非常实用。 cat << EOF > /tmp/malformed_data.txt 1 {1} 1 a {2} 2 3 {3} 3333333333 4 {a, 4} 4 5 {5} 5 EOF 之前在用 COPY 导入数据时，如果文件中有不符合类型的字段，命令直接报错退出: postgres=# CREATE TABLE check_ign_err (n int, m int[], k int); CREATE TABLE postgres=# copy check_ign_err from '/tmp/malformed_data.txt'; ERROR: invalid input syntax for type integer: " a" CONTEXT: COPY check_ign_err, line 2, column n: " a" postgres=# table check_ign_err; n | m | k ---+---+--- (0 rows) PostgreSQL 17 增加了如下语法:...

PostgreSQL 17 的一个重要特性是在内核层面增加了增量备份（Incremental Backup）的特性，为用户提供更灵活和高效的备份解决方案。 该特性由 EDB 的首席数据库架构师 Robert Haas 实现，详细讨论见: trying again to get incremental backup Why Incremental Backup? PostgreSQL 通过全量备份和 WAL archiving 能够实现 PITR(Point-In-Time Recovery)，从功能完备性角度来讲，也许并不需要增量备份。但对一个 10T 数据量、读多写少的实例，每周（月）进行一次全量备份可能太过繁重。 增量备份则仅备份自上次备份（可以是全量备份或增量备份）以来修改过的文件页面（8K Block），对于数据量大且修改频率较低的数据库实例，增量备份有以下优势： 快速备份：由于增量备份只包含自上次备份以来的变化部分，因此备份速度更快。相比全量备份，增量备份需要拷贝的数据量更小，能够更快地完成备份过程。 空间效率：由于增量备份仅存储自上次备份以来的更改部分，所需的磁盘空间较少，节省存储成本。 快速恢复：在数据丢失或灾难恢复的情况下，从全量+增量备份进行恢复通常比从全量备份+WAL进行恢复更快。将最近的全量备份和后续的增量备份进行合并，相比回放大量的 WAL 日志，恢复时间更短，可以快速使系统恢复正常运行。 EDB 工程师 Jakub Wartak 进行的测试证明了增量备份的必要性: 对一个初始数据量 3.5G 的实例用 pg_bench 持续写入，24 小时生成的 WAL 数据量 77GB，最后一次的增量备份数据量 3.5GB，相对最终的总数据量 4.3GB 差距不明显，说明大部分页面有过改动。 全量+增量备份 恢复的速度（4min18s）却远快于全量备份+WAL（78min）。 当然，增量备份也并非银弹，增量备份文档中有这样一段描述: Incremental backups typically only make sense for relatively large databases where a significant portion of the data does not change, or only changes slowly....