PostgreSQL 13.0-13.15 功能更新和bug fixed列表

文摘   2024-09-09 06:02   中国香港  

开头还是介绍一下群,如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis, OceanBase, Sql Server等有问题,有需求都可以加群群内有各大数据库行业大咖,可以解决你的问题。加群请联系 liuaustin3 ,(共2370人左右 1 + 2 + 3 + 4 +5 + 6 + 7)(1 2 3 4 5 群均已爆满,请不要在问有没有位置谢谢)

在总结了PostgreSQL 12 14 15 16版本的release note和bug fixed的细节后,此次总结最后的一部分 PG13的release note里面的信息。PG13 有15个版本,我们从PG13.1 开始

PostgreSQL 13 版本对于PG是一个重要的版本,在PG11中对于分区表的未改进的情况下,PG12对于分区表有了重大的改进,但基于稳定性功能上来说我们需要一个更平稳的平台,所以大部分企业选择了PG13这个版本作为生产中使用的版本,在这个版本中对于一些问题进行了更新和解决。

1  B-tree索引聚合函数或分区表的查询性能的提升 2  改进了使用聚合函数或分区表的查询性能 3  在使用扩展统计信息时改进了规则 4  索引的并行化清理 5  增量排序

注意:如果选择PG13 要选择PG13.5以上的版本之前的版本对在线索引有一些问题的修复,虽然是不经常发生的情况下丢数据。如果使用生成列,请注意在PG13.11后的版本使用,避免产生错误数据,基本在PG 13.4 13.5两个版本都是比较小的改动并不大。

版本号BUG FIXED/功能更新
PG13.0wal_keep_segments 改名为 wal_keep_size
PG13.0移除了7.0 8.0 之前的语法定语的运算符支持和外键约束的支持
pg13.0不在支持create extension from 选项
PG13.0修复pageinspect 中的bt_metap()内存移除的问题
PG13.0允许在分区表中使用整行变量(即,table.*)作为分区表达式
PG13.0允许 GIN 索引更高效地处理 tsquery 搜索中的 !(NOT)子句
PG13.0允许 CREATE INDEX 指定 GiST 签名长度和整数范围的最大数量
PG13.0防止使用非默认排序规则的索引添加为表的唯一约束或主键约束
PG13.0允许在单个查询中使用多个扩展统计信息对象
PG13.0允许使用扩展统计信息对象用于 OR 子句和 IN/ANY 常量列表
PG13.0允许哈希聚合在大型聚合结果集上使用磁盘存储
PG13.0新增autovacuum_vacuum_insert_threshold 和 autovacuum_vacuum_insert_scale_factor
PG13.0在使用多个表空间时,改进重放 DROP DATABASE 命令的性能
PG13.0maintenance_io_concurrency 参数添加
PG13.0允许在创建或重写关系的事务中跳过 WAL 写入,如果 wal_level 是最低级别
PG13.0改进 TOAST 值的前导字节的检索性能
PG13.0添加系统视图 pg_stat_progress_basebackup 以报告流式备份的进度
PG13.0添加系统视图 pg_stat_progress_analyze 以报告 ANALYZE 进度
PG13.0添加系统视图 pg_shmem_allocations 以显示共享内存使用情况
PG13.0添加等待事件 VacuumDelay 以报告基于成本的 VACUUM 延迟
PG13.0在 Windows 上启用对 Unix 域套接字的支持
PG13.0允许通过 max_slot_wal_keep_size 限制复制槽的 WAL 存储
PG13.0允许在 standby 提升过程中取消任何请求的暂停
PG13.0允许 VACUUM 并行处理表的索引
PG13.0允许 psql 的 \g 和 \gx 命令更改单个命令的 \pset 输出选项
PG13.0新命令为 \dAc、\dAf、\dAo 和 \dAp。在 verbose 模式下,psql 的 \dt+ 和相关命令显示表持久性
PG13.0允许 pgbench 对其“accounts”表进行分区
PG13.0使 pg_basebackup 默认估算总体备份大小,此计算允许 pg_stat_progress_basebackup 显示进度。如果不需要该功能,可以使用 --no-estimate-size 选项禁用。以前,仅在使用 --progress 选项时才进行这种计算
PG13.0允许 vacuumdb 运行的 VACUUM 命令以并行模式运行

PG13.1

版本号BUG FIXED/功能更新
PG13.1修复了在pg_dump、pg_restore和相关程序中的一个问题,其中复杂的连接字符串参数未被正确使用,可能导致连接失败或安全漏洞。
PG13.1更新了psql的\connect命令的行为,以确保所有相关连接参数都被正确复用,从而防止潜在的连接失败或安全漏洞。
PG13.1修补了psql中\gset命令修改特殊处理变量的问题,可能被利用执行任意 shell 代码。此漏洞由Nick Cleaton发现,由Noah Misch处理。
PG13.1当archive_mode设置为always时,确保备用服务器能够归档WAL时间线历史文件,防止PITR恢复数据失败
PG13.1修复TOAST解压缩时可能导致无限循环或输出数据损坏的情况
PG13.1在仅进行清理型VACUUM时计算B-树索引中条目数量的修复
PG13.1修复索引条目不应包含超出线TOAST指针,但BRIN并未收到该备忘录。这可能导致错误,如“丢失的TOAST值NNN的第0块”。
PG13.1在Windows上,确保psql以文本模式读取反引号命令的输出,而不是二进制模式
PG13.1确保pg_dump收集关于扩展配置表的每列信息,未执行此操作会导致指定--inserts时出现崩溃,或使用COPY重新加载表数据时出现不完整(尽管通常正确)的COPY命令。
PG13.1在contrib/pgcrypto中修复潜在的内存泄漏
PG13.1修复了一些连接查询中未检查每列SELECT权限失败的问题
PG13.1修复了CREATE INDEX CONCURRENTLY等待并发准备事务的问题
PG13.1修复了contrib/pg_prewarm和contrib/postgres_fdw中超时计算错误的问题
PG13.1Fix memory leak in contrib/auto_explain

PG13.2

版本号BUG FIXED/功能更新
PG13.2修复了一些连接查询中未检查每列SELECT权限失败的问题
PG13.2修复了CREATE INDEX CONCURRENTLY等待并发准备事务的问题
PG13.2避免在尝试重新扫描同时具有哈希和排序分组集的聚合计划节点时崩溃
PG13.2修复在哈希聚合节点将某些元组溢出到磁盘时可能导致查询结果不正确的问题
PG13.2当通过扩展查询协议执行执行事务回滚的CALL或DO语句时避免崩溃
PG13.2使contrib/pg_prewarm在集群在预热完成之前关闭时更加健壮,此前,autoprewarm将其状态文件重写为目前已加载的块编号,因此可能在下一次启动时基本上禁用预热功能。相反,在初始加载通过完成之前,抑制状态文件更新。
PG13.2在contrib/pg_trgm的GiST索引支持中,避免在仅调用两个索引项的罕见情况下发生崩溃(Andrew Gierth,Alexander Korotkov)
PG13.2修复了contrib/pg_prewarm和contrib/postgres_fdw中超时计算错误的问题
PG13.2使contrib/pg_prewarm在簇在预热完成之前关闭时更加健壮,以前,autoprewarm会将其状态文件重新写入为到目前为止已加载的块编号,因此可能会大部分地在下一次启动中禁用预热功能。相反,直到初始加载完成前抑制状态文件更新。
PG13.2修复了contrib/pg_prewarm和contrib/postgres_fdw中超时计算错误的问题

PG13.3

版本号BUG FIXED/功能更新
PG13.3数组代码以前不会在数组的下限加长度溢出整数的情况下报错。这使得数组中的后续条目变得不可访问(因为它们的下标无法被写入整数),但更重要的是,它混淆了后续的赋值操作。这可能导致内存覆写,随之而来的崩溃或不希望的数据修改。
PG13.3修复了在INSERT ... ON CONFLICT ... UPDATE目标列表中处理“垃圾”列的错误
PG13.3修复了连接跨分区更新的UPDATE ... RETURNING结果可能不正确计算的问题
PG13.3如果针对分区表的UPDATE导致行移动到具有物理上不同行类型的另一个分区(例如,包含不同一组已删除列的行),为该行计算的RETURNING结果可能会产生错误或错误的答案。除非UPDATE涉及其他表与目标表的连接,否则不会观察到错误
PG13.3在使用ALTER TABLE ... INHERIT附加子表时,坚持父表中的任何生成列在子表中以相同方式生成
PG13.3确保REINDEX CONCURRENTLY保留为索引设置的任何统计目标
PG13.3修复将COLLATE表达式结果强制转换为不可排序类型时出现的错误
PG13.3在使用扩展统计信息估计组数量时,不要忽略系统列
PG13.3修复了当GIN tsvector索引搜索匹配元组很多时可能产生错误答案的问题
PG13.3在从WAL恢复未提交的两阶段事务时确保正确的时间线更改,此错误可能导致后续WAL记录按错误的时间线ID写入,导致一致性问题,甚至在以后重启服务器时完全无法重启。
PG13.3禁用vacuum_cleanup_index_scale_factor参数和存储选项
PG13.3修复psql的ON_ERROR_ROLLBACK功能以正确处理COMMIT AND CHAIN命令
PG13.3在pg_restore中修复遗漏的文件版本检查
PG13.3修复在pg_checksums中不正确的进度报告计算

PG13.4

版本号BUG FIXED/功能更新
PG13.4修复SQL执行器在执行路径重叠中产生错误执行计划的问题
PG13.4在存储过程中的COMMIT或ROLLBACK后恢复Portal级别的快照,此更改修复了在COMMIT/ROLLBACK后立即尝试获取托管值时可能会导致错误,如“没有已知快照”或“缺失的分块编号 0 对于托管值”。
PG13.4在持久化读取非稳定查询的游标的输出时,避免行为不当
PG13.4拒绝SELECT ... GROUP BY GROUPING SETS (()) FOR UPDATE,这应当被禁止,就像带有普通GROUP BY的FOR UPDATE被禁止一样,但对空分组集的测试无法正确处理。最终结果将是执行器中的空指针取消引用。
PG13.4在数字乘法中,如果小数点后的位数超过16383位,则四舍五入结果而不是失败
PG13.4修复在使用EEEE格式和小于10^(-1001)的数字输入值时,to_char()中的除零故障
PG13.4在添加或删除成员对象时,使ALTER EXTENSION锁定扩展,先前的编码允许ALTER EXTENSION ADD/DROP与DROP EXTENSION同时发生,导致崩溃或损坏目录条目。
PG13.4修复PREPARE TRANSACTION以正确检查会话寿命锁和事务寿命锁之间是否存在冲突
PG13.4使walsenders在pg_stat_activity中显示其最新的复制命令,以前,walsender会显示其最新的SQL命令,如果现在正在执行一些复制操作,这会导致混淆。现在我们将复制协议命令与SQL命令同等对待。
PG13.4在64位Windows上,允许work_mem乘以hash_mem_multiplier的有效值超过2GB,这样可以确保hash_mem_multiplier可以用于防止大型哈希聚合溢出到磁盘,即使“大型”意味着多个GB。修复涉及作为外键表的继承子表的常规表的查询的规划错误
PG13.4在WAL重放事务中引起文件截断时更新最低恢复点文件截断是不可逆转的,因此不再安全地在该记录之前停止恢复。事务提交的相应案例在多年前已经修复,但这个案例被忽视了
PG13.4修复pg_dump以正确处理已启用状态与父触发器状态不同的分区表上的触发器
PG13.4避免在以不同时区创建的存档文件上运行pg_restore时出现“头部中的无效创建日期”警告
PG13.4解决在在压缩和非压缩WAL存储之间切换时发生问题
PG13.4修复contrib/postgres_fdw以有效地处理生成的列

PG13.5

版本号BUG FIXED/功能更新
PG13.5拒绝在SSL或GSS加密握手后拒绝附加数据,拦截能够向TCP连接注入数据的人中间可能在应该加密保护的数据库会话的开始处注入一些明文数据。虽然这可以被滥用以向服务器发送伪造的SQL命令,但这仅在服务器不要求任何身份验证数据时才会起作用。(但是,依赖SSL证书身份验证的服务器很可能不会这样做。)
PG13.5使libpq在SSL或GSS加密握手后拒绝附加数据,一个人中间者可以向TCP连接注入数据,将一些明文数据塞入应该加密保护的数据库会话的开头。可能会被滥用以注入假响应给客户端的前几个查询,虽然libpq的其他行为细节使这变得比听起来的更加困难。另一种攻击方式是窃取客户端的密码或其他可能早期在会话中发送的敏感数据。已经证明对于受CVE-2021-23214影响的服务器来说这是可能的。
PG13.5修复主节点在传输以部分WAL记录结尾的WAL段后发生崩溃的物理复制的情况,如果主节点没有幸存足够长的时间来完成其余不完整的WAL记录的编写,那么以前的崩溃恢复逻辑会备份并覆盖从不完整WAL记录的开始开始的WAL。这是有问题的,因为备用服务器可能已经有那个WAL段的副本。然后它们将看到不一致的下一个段,而且无法在没有手动干预的情况下恢复。为了解决这个问题,在崩溃后重新启动时不要在WAL段边界上备份。取而代之的是,在下一个WAL段的开始写入一种新类型的WAL记录,通知读取者不完整的WAL记录永远不会完成,必须被忽略。
PG13.5修复CREATE INDEX CONCURRENTLY以等候最新的准备事务,此类问题的以前修复未考虑在CREATE INDEX CONCURRENTLY检查准备事务时仍在进行中的PREPARE TRANSACTION命令
PG13.5避免在使用SELECT FOR UPDATE的规则中尝试锁定OLD和NEW伪关系
PG13.5确保在重命名表时使用正确的锁级别,由于历史原因,ALTER INDEX … RENAME可应用于任何类型的关系。重命名索引所需的锁级别低于重命名表或其他类型关系所需的级别,但代码错误,当命令拼写为ALTER INDEX时会使用较弱的锁级别。
PG13.5避免在LLVM内部发生错误后清理LLVM状态时出现空指针解引用崩溃,这可以防止在致命LLVM错误后在后端退出期间崩溃。
PG13.5避免在删除同时拥有正在同时删除的对象的角色时发生空指针解引用崩溃
PG13.5确保在统计视图中计算SP-GiST索引的扫描次数,SP-GiST代码中忽略了增加索引扫描次数的计数器,尽管每个元组的计数器正确地增加。
PG13.5在修复中逐次调整涉及recovery_min_apply_delay在恢复期间更改的相关等待间隔
PG13.5确保在发生套接字级别故障时pgbench以非零状态退出
PG13.5修复contrib/postgres_fdw在尝试报告数据转换错误时发生空指针崩溃
PG13.5使pg_regexec()对超出范围的search_start参数具有强大的容错性,当search_start超出字符串末尾时返回REG_NOMATCH,而不是可能导致崩溃。这种情况在核心PostgreSQL中可能无法到达,但扩展可能更加粗心地设置参数值。

PG13.6

版本号BUG FIXED/功能更新
PG13.6强制实施TOAST表更新的标准锁定协议,以防止REINDEX CONCURRENTLY引起问题,如果应用于TOAST表或TOAST表的索引,REINDEX CONCURRENTLY往往会生成一个损坏的索引。这是因为更新TOAST条目的会话会立即释放其行互斥锁,而不像所有其他更新一样在事务提交之前保持这些锁。修复方法是使TOAST更新按照正常规则持有表锁。任何现有的损坏索引可以通过重新索引来修复。
PG13.6避免在同时删除统计对象时在ALTER STATISTICS中发生空指针崩溃,
PG13.6修复只索引扫描计划的情况,其中无法返回所有索引列,如果一个索引既有可返回的列,又有不可返回的列,并且其中一个不可返回的列是使用出现在可返回索引列中的表列的表达式,那么使用该表达式的查询可能导致尝试读取不可返回列的只索引扫描计划,而不是按预期从可返回列中重新计算表达式。不可返回列将读取为NULL,导致错误的查询结果。
PG13.6修复检查任意兼容族数据类型匹配的问题
PG13.6修复当数据库一致性恰好在WAL页面边界处达到时的WAL重播失败
PG13.6修复物理复制的启动以容忍事务ID换向,如果在主服务器上的活动事务集跨越换向边界时(这样在较早的事务中存在比较新的XID更小的XID),副本服务器启动时会失败,并显示“在KnownAssignedXids中的顺序XID插入超出范围”。副本会重试,但永远无法越过该错误。
PG13.6移除在逻辑复制连接上发出的SQL命令的词法限制,walsender进程将对包含未引用分号、包含奇数个单引号或双引号的dollar引用文字,或者当SQL命令以注释开头时失败。此外,错误的错误恢复可能导致后续命令中的意外错误。
PG13.6确保在检查点期间对pg_logical/mappings子目录进行fsync
PG13.6为分区表构建扩展统计信息,之前的一个bug修复禁用了为旧式继承树构建扩展统计信息,但也阻止了为分区表构建统计信息,这是一个不必要的限制。这个变化允许ANALYZE为分区表计算统计对象的值。
PG13.6忽略继承树的扩展统计信息,目前,扩展统计信息的值仅为每个表在本地计算,而不为整个继承树计算。但是,在规划跨继承树查询时错误地查询了这些值,可能导致比默认估计更糟糕的结果。
PG13.6禁止对作为复制标识索引的列进行ALTER TABLE ... DROP NOT NULL,对于主键索引,已经存在相同的禁止。
PG13.6在ALTER TABLE ADD PRIMARY KEY USING INDEX时正确更新缓存表状态,并行会话未能更新其对于表是否有主键的看法,可能导致不正确的逻辑复制行为。
PG13.6在切换REPLICA IDENTITY索引时正确更新缓存表状态,并行会话未能更新其关于哪个索引是复制标识索引的看法,可能导致不正确的逻辑复制行为。
PG13.6允许忽略计算最早xmin时的并行清理和并行索引构建,对这些操作的非并行化实例已经被忽略,但是对于并行化情况逻辑却不起作用。抑制xmin的水平会造成不良影响,比如延迟清理。
PG13.6通过避免不必要的缓存访问来改善walsenders发送逻辑变化的性能
PG13.6修复出现在INSERT ... VALUES规则中的整行变量的显示问题,整行变量将被打印为“var.*”,但这样做允许在重新加载规则时将其扩展为单独的列,导致不同的语义。附加一个显式转换来防止这种情况发生,就像我们在其他地方做的一样。
PG13.6在将Unicode字符串规范化为空字符串时修复一个字节缓冲溢出
PG13.6修复可能导致在多线程使用libpq或ecpglib时不能正确定位早期报告的错误消息的竞争条件
PG13.6使psql的\password命令默认为为CURRENT_USER设置密码,而不是连接的原始用户名

PG13.7

版本号BUG FIXED/功能更新
PG13.7停止对引用普通表的整行变量的列使用查询提供的列别名,由整行变量产生的元组的列名目前总是与相关的命名复合类型相同,如果有的话,不再跟踪该别名所应用于的FROM条目。我们此前曾尝试使它们跟踪变量所引用的FROM条目上已应用的任何列别名。但这在语义上是可疑的,因为实际上变量的输出根本不是它所声称的复合类型。之前尝试解决这种不一致性的结果包括在磁盘上存储不可读的数据,因此我们放弃整个想法。
PG13.7避免对不包含列的VALUES子句进行内核转储
PG13.7修正引用外部查询级别的GROUPING()结构所导致的计划错误
PG13.7修复在同时具有可返回列和不可返回列的索引上进行索引仅扫描的计划生成,之前的编码可能会尝试读取非可返回列,除了可返回列。这是相当无害的,因为它实际上并未处理无效值,但它违反了最近添加的错误检查,该检查拒绝了这样的计划。
PG13.7在EvalPlanQual期间尝试锁定过时元组时,避免访问不再固定的共享缓冲区,该代码会在释放钉住之后再触摸该缓冲区几次。理论上,一旦钉住消失,另一个进程就可以回收缓冲区(或更有可能,尝试对其空闲空间进行碎片整理)从而导致找不到元组的更新版本
PG13.7修复在执行重新排序的IndexScan节点中的查询生命周期内存泄漏
PG13.7修复使用其前导键为表达式的索引进行CLUSTER时表行的错误排序,表将使用正确的数据重建,但排序顺序与索引顺序关系不大。
PG13.7修复DROP TABLESPACE和检查点之间的竞争条件,通过DROP TABLESPACE强制的检查点有时可能无法从表空间目录中删除所有死文件,导致虚假的“表空间不为空”错误。
PG13.7修复在TRUNCATE命令与检查点重叠之后的崩溃恢复中可能出现问题,TRUNCATE必须确保在允许检查点完成之前截断表的磁盘文件。否则,从那个检查点开始的重放可能会在据称已删除的页中找到意外数据,可能导致重放失败。
PG13.7修复在临时对象清理期间不安全的toast数据访问,服务器进程退出期间的临时对象删除可能会出现“致命错误:不能在没有活动快照的情况下获取toast数据”。这通常是无害的,因为下一个对该临时模式的使用将成功清理。
PG13.7解决在缺少WAL连续记录时进行备库升级时出现“PANIC:xlog flush request is not satisfied”的故障
PG13.7修复热备冲突处理中死锁的可能性,在不幸的时机下,等待某个其他进程释放缓冲区锁时,WAL应用过程可能会卡住。
PG13.7修正发布逻辑复制更改时可能错误识别正确的祖先关系,如果启用了publish_via_partition_root,并且有多个发布命名目前修改的关系的不同祖先,可能会选择错误的祖先来报告更改。
PG13.7确保逻辑复制应用工作进程即使达到max_sync_workers_per_subscription限制也能重新启动
PG13.7使pg_ctl在等待停止/重新启动/晋升操作时重新检查控制进程是否存活,pg_ctl将验证控制进程是否活动是发送停止或晋升信号的副作用,但之后它只是简单地等待看磁盘状态是否改变。如果控制进程不干净地死掉而没有移除其PID文件或更新控制文件,pg_ctl将等待超时。相反,让它定期重新检查控制进程是否仍在那里。
PG13.7修复pg_waldump中的错误处理,在尝试读取WAL文件以确定WAL段大小时,pg_waldump可能会对文件太短的情况报告不正确的错误。此外,在这个和相关的错误消息中报告的文件名可能是垃圾。
PG13.7确保contrib/pageinspect函数处理所有零页
PG13.7在contrib/pageinspect中,增加防御措施以防止不正确的页面“特殊空间”内容,加强对正确页面大小的检查,并添加一些缺失的检查来确认索引是预期类型的
PG13.7在contrib/postgres_fdw中,在请求远程有序查询之前验证ORDER BY子句是否安全,如有必要,添加USING子句,此修复防止远程服务器可能按我们意图的不同顺序排序。虽然有时只是表面的,但如果远程数据作为本地执行的合并连接的输入,可能会产生完全错误的结果。
PG13.7修复PL/Perl使其能在不支持表达式内嵌语句的C编译器上构建

PG13.8

版本号BUG FIXED/功能更新
PG13.8不允许扩展脚本替换非属于扩展的对象,这个更改防止扩展脚本在存在不属于该扩展的现有对象时执行CREATE OR REPLACE。它还阻止在相同情况下执行CREATE IF NOT EXISTS。这可以防止一种特殊的特洛伊木马攻击,即恶意数据库用户可能成为扩展对象的所有者,然后修改它以 compromise 其他用户未来使用该对象的可能性。另外,它也降低了意外替换本不想替换的对象的风险。
PG13.8修复在备用服务器上重放CREATE DATABASE WAL 记录时的问题,当备用服务器重放创建数据库的WAL记录时,可能会遇到缺少的表空间目录。在此补丁之前,如果发生这种情况,备用服务器将无法恢复;但是,这样的目录可能确实缺失。创建表空间(作为普通目录),然后在重放达到一致状态时检查它是否已被删除。
PG13.8修复ALTER TABLE ... ENABLE/DISABLE TRIGGER在处理分区表触发器递归时正确处理的问题
PG13.8改进类型jsonpath的语法错误消息
PG13.8防止pg_stat_get_subscription() 可能返回包含垃圾值的额外行,确保pg_stop_backup()正确清理会话状态
PG13.8修复在FOR [KEY] UPDATE/SHARE子句中的连接别名匹配
PG13.8拒绝在FROM中具有太多列的ROW()表达式和函数,有关1600列以上的情况是不受支持的,并且总是在执行时失败。然而,出现了一些更早的代码可能被驱动到断言失败或崩溃的查询,其列数超过32K的情况。添加一个解析时检查,以防止这种情况发生。
PG13.8这个疏忽可能导致dump/reload或pg_upgrade失败,因为dumped视图会为该函数的列具有太多列别名。向事件触发器报告隐式创建的运算符族
PG13.8修复当备用服务器提升期间重新启动点正在运行时所做的控制文件更新
PG13.8防止逻辑复制大事务期间触发备用服务器的wal_receiver_timeout,如果主服务器上的大事务没有向备用服务器发送任何数据(可能是因为它所更改的表没有发布),备用服务器可能会超时。通过确保在这种情况下定期发送保持活动消息来修复此问题。
PG13.8禁止在逻辑复制的walsender中进行嵌套备份操作
PG13.8修复在发布者进行架构更改后,逻辑复制订阅者中缓存的架构数据更新失败的问题
PG13.8修复在共享哈希表管理中的错误断言检查
PG13.8在psql的 \watch 命令中,在用Ctrl-C取消后回显一个换行符
PG13.8修复了contrib/pg_stat_statements在32位平台上处理非常大的查询文本文件时可能出现的问题

PG13.9

版本号BUG FIXED/功能更新
PG13.9避免在与VACUUM同时进行的更新中发生罕见的PANIC,如果并发的VACUUM在一个页面中设置了所有可见标记位,而UPDATE或DELETE正在修改该页面,那么更新命令需要再次清除该位;但一些代码路径未能做到这一点,最终导致PANIC退出和数据库重新启动
PG13.9修复VACUUM,如果尝试删除B-tree索引中的页面失败无法找到页面的父链接(
PG13.9在执行ALTER TABLE ATTACH PARTITION时修复构建每个分区外键约束的bu
PG13.9修复在创建分区索引时匹配索引表达式和谓词的错误
PG13.9修复为每个分区外键约束生成约束名称的bug,如果最初给定的名称已经被某个分区的某个约束使用,那么会选择一个新的名称;但实际上没有按照预期拼写出来。
PG13.9修复创建分区索引时索引表达式和谓词不匹配的问题,在创建分区索引时,我们尝试识别与分区索引匹配的现有索引,以便将其作为子索引吸收而不是构建新的索引。表达式的匹配没有正确进行,因此一个可用的子索引可能被忽略,导致创建重复的索引。
PG13.9在备机升级后避免WAL数据损坏,当一个执行归档恢复但不使用备用模式的PostgreSQL实例被升级时,如果它试图读取的最后一个WAL段以部分记录结尾,实例会在新时间轴上写入一个无效的WAL段。
PG13.9修复GIN索引快速插入路径中WAL操作的错误排序
PG13.9在逻辑解码期间防止使用错误的快照检查系统目录,如果解码从修改系统目录的事务的一部分开始,解码器可能不会意识到这一点,导致它无法将该事务视为进行中以进行目录查找。
PG13.9删除对分区表副本标识设置的毫无意义的检查,最重要的是叶子分区的副本标识设置,因此如果在父分区上没有设置,就不需要抛出错误。
PG13.9避免在复制工作进程中函数语法错误后崩溃,如果在逻辑复制工作进程中执行SQL语言或PL/pgSQL语言的CREATE FUNCTION或DO命令时出现语法错误,工作进程将会因为空指针引用或断言失败而崩溃。
PG13.9修复将read-write扩展数据传递给SQL函数时的使用后释放风险,如果一个非内联的SQL函数在多个地方使用参数,并且其中一个函数希望能够就地修改read-write数据,那么稍后对参数的使用将观察到错误的值。
PG13.9在共享内存状态损坏时防止postmaster崩溃,postmaster进程应该在共享内存损坏时幸存下来并启动数据库重启,但某部分代码对此的谨慎性不够。
PG13.9避免在work_mem非常小且元组很大的情况下选择哈希表大小时出现错误行为
PG13.9避免autovacuum launcher进程中的长期内存泄漏
PG13.9允许在任何机器上使用__sync_lock_test_and_set()进行自旋锁

PG13.10

版本号BUG FIXED/功能更新
PG13.10允许在尚未标记为有效的索引上设置REPLICA_IDENTITY,当pg_dump转储一个标记为REPLICA_IDENTITY的分区索引时,它生成的命令序列会在将分区索引标记为有效之前就应用REPLICA_IDENTITY,导致恢复失败。似乎没有很好的理由禁止按照这种顺序进行操作,因此允许该操作。直到索引变为有效之前,标记将不会生效。
PG13.10修复并行哈希连接中的边缘案例数据损坏,如果一个大元组的最终块要写入临时文件的大小恰好为32760字节,由于一个错误,它将会被损坏。查询通常会在稍后由于数据损坏的症状而失败。
PG13.10在recovery_target_xid模式中记录正确的结束时间戳,当根据设置的recovery_target_xid结束恢复时,如果设置recovery_target_inclusive = off,则会在“恢复在...事务之前停止”日志消息中打印一个不正确的时间戳
PG13.10改进一些缓冲文件读取失败的错误报告,正确报告短读取,给出期望读取的字节数和实际读取的字节数,而不是报告一个无关的错误代码。大多数地方已经做到了,但一些最近编写的复制逻辑没有。
PG13.10防止在VACUUM结束时“错误的元组长度”失败,如果VACUUM需要更新当前数据库的datfrozenxid值,并且数据库具有很多已授予权限,导致其datacl值被推出行,则会发生这种情况。
PG13.10在扩展查询协议中,在运行流水线时避免在ANALYZE后进行立即提交,如果没有明确的BEGIN TRANSACTION,ANALYZE将自行提交,这在一系列命令中进行时是不应该发生的。
PG13.10在子查询提取中添加递归和循环防御,一种刻意构造的查询可能导致深度递归和大量时间被用来尝试展开子查询。对于这种情况的适当修复似乎对于后端补丁过于侵入性,但至少我们可以添加堆栈深度检查和中断检查,以允许查询被取消。
PG13.10确保在执行全文搜索查询时可以取消执行短语匹配
PG13.10修复具有非确定性排序规则的字符串哈希中的内存泄漏
PG13.10在失败的复制连接尝试后清理libpq连接对象,先前的代码泄漏了连接对象。在后台代码路径中,这并不会有太大的影响,因为调用进程将放弃并退出。但是在诸如CREATE SUBSCRIPTION等命令中,这样的失败会导致一个小的会话寿命内存泄漏。
PG13.10在热备服务器中,减少在主服务器上已知活动XID跟踪的处理工作量,对KnownAssignedXids数组的清理不够积极可能导致性能不佳,特别是当在备用服务器上设置max_connections为一个大值时。
PG13.10在确定最旧的目录xmin时忽略无效的逻辑复制插槽,一个复制插槽可能会阻止系统目录中死元组的清理,即使由于超过max_slot_wal_keep_size而使其失效。因此,复制使用者的失败可能导致目录无限增大。
PG13.10修复逻辑解码中未初始化内存使用,在某些情况下,逻辑解码的恢复可能会尝试重新使用已经被释放的XID数据,导致行为不可预测。
PG13.10在WAL重放哈希索引页拆分操作期间避免“失败以获取清理锁定”的罕见恐慌
PG13.10在WAL重放期间设置堆页面的全可见位时推进LSN,未执行此操作将导致从主服务器到备用服务器的页面可能不同,并违反有关LSN何时更改的其他期望。就PostgreSQL本身而言,这似乎只是一个理论上的风险,但可能会扰乱第三方工具。

PG13.11

版本号BUG FIXED/功能更新
PG13.11防止CREATE SCHEMA命令破坏search_path中的更改,在CREATE SCHEMA命令中,当前search_path中的对象以及新创建的模式中的对象将在试图设置安全search_path的调用函数或脚本中可见。这可能允许任何有权限创建模式的用户劫持安全定义函数或扩展脚本的特权。
PG13.11避免在CREATE SCHEMA中省略新模式名称时出现崩溃,SQL标准允许编写CREATE SCHEMA AUTHORIZATION owner_name,其中模式名称默认为owner_name。然而,某些代码路径期望模式名称存在,并且会失败。
PG13.11修复分区表中克隆触发器的启用/禁用,ALTER TABLE … ENABLE/DISABLE TRIGGER USER跳过了克隆的触发器,错误地将它们错认为是系统触发器。其他启用/禁用触发器的变体会处理它们,但是在不正确地执行超级用户检查之后才会处理。
PG13.11禁止修改存储在索引中的复合类型,如果在任何表列中存储复合类型,则ALTER TYPE将不允许不兼容的修改。(也许将来会允许,但目前尚未发生;重写许多表的锁定影响令人生畏。)我们忽略了索引可能包含一个不在表中出现的复合类型的可能性。
PG13.11禁止系统列作为外键的元素,自从系统列OID被移除以来,不存在明显的用例,而且各种代码现在不再支持它。不要尝试修复所有这些情况,而是禁止它。
PG13.11修复to_char()中可能的越界访问(
PG13.11在使用删除功能时,该函数可能会获取输入字符串之后的字节,从而导致小概率的崩溃风险。
PG13.11修复JSON字符串文本中的解析错误时,错误的光标设置,检测到JSON值中字符串文本存在语法错误的大多数情况下未正确设置错误光标。这至少导致了一个不太有用的错误消息(指向字符串之前的标记,而不是实际出问题的地方),在v14及更高版本甚至可能导致崩溃。
PG13.11修复由于vacuum_defer_cleanup_age大于当前64位xid而导致的数据损坏,在v14及更高版本中,如果未默认设置vacuum_defer_cleanup_age,可能会计算出一个非常大的vacuum清理界限xid,导致vacuum删除仍然存活的行。v12和v13存在一个更小形式的相同问题,只影响GiST索引,可能导致索引页过早回收。
PG13.11修复解析器未能检测某些不正确嵌套聚合的情况
PG13.11修正在解析序列SEQUENCE NAME选项期间数据结构损坏
PG13.11在更新包含域-复合类型列数组中的字段时,防止崩溃
PG13.11修复并行哈希连接中每批次清理的竞争条件,在不幸的计时和parallel_leader_participation = off(不是默认情况)的情况下,可能导致崩溃。
PG13.11在EvalPlanQual检查后重新计算生成的列,在READ COMMITTED隔离模式下,一个行更新的影响可能需要重新应用到比查询最初发现的行版本更新的版本。如果是这样,我们需要重新计算任何生成的列,以防它们依赖于被并发更新改变的列。
PG13.11当表具有零值的单个关系vacuum_cost_delay设置时,不平衡vacuum cost delay,每当autovacuum处理具有单个关系vacuum_cost_delay设置的表时,延迟平衡应该被禁用,但这仅适用于正值设置,而不是零值。
PG13.11在解析包含WITH中的INSERT/UPDATE/DELETE的规则或SQL函数体时,注意打印目标表的正确别名
PG13.11修复SERIALIZABLE READ ONLY优化中的故障,对于已标记为“绝望”的事务,为SERIALIZABLE READ ONLY事务进行安全快照优化会混淆。在某些情况下,优化会不必要地被跳过。在其他情况下会发生断言失败
PG13.11修复pg_dump,使得对枚举列进行哈希分区的分区表可以成功恢复,由于枚举值的哈希代码取决于为枚举分配的OID,因此在转储和恢复后通常会不同,意味着行通常需要进入与原始不同的分区。用户可以通过指定--load-via-partition-root选项来解决这个问题;但在没有这个选项的情况下几乎没有成功的机会,因此教导pg_dump自动将其应用于这种表
PG13.11在contrib/hstore_plpython中,避免在要转换的Python值不是映射时崩溃
PG13.11在contrib/pg_trgm中修复不可满足正则表达式的错误行为,像$foo这样的正则表达式是合法但不可满足的;正则表达式编译器识别到这一点并生成一个空的NFA图。试图优化这样的图形成pg_trgm GIN或GiST索引限定条件会导致访问工作数组的结束,可能导致崩溃。

PG13.12

版本号BUG FIXED/功能更新
PG13.12修复BRIN索引中空(无行)范围和所有NULL范围之间的混淆,以及所有NULL摘要的不正确合并,这个修复本身不会修正错误的BRIN条目。建议重新索引任何可能用于搜索空值的BRIN索引。
PG13.12在中断DROP DATABASE时避免留下损坏的数据库,如果DROP DATABASE在已开始执行不可逆步骤后被中断,目标数据库仍然可访问(因为其pg_database行的删除将回滚),但其内容可能已损坏。修复方法是在执行不可逆操作之前将数据库标记为不可访问。之后的失败会使数据库仍然部分存在,但除了发出另一个DROP DATABASE命令外,没有其他操作。
PG13.12确保创建分区索引时正确标记为有效或无效,如果新的分区索引与某个分区上现有但无效的索引匹配,则分区索引可能会过早地被标记为有效。这可能导致对分区表的后续查询中出现错误或断言失败。
PG13.12在ALTER TABLE ATTACH PARTITION期间,匹配分区索引与子索引时忽略无效的子索引,现在将忽略这样的索引,并创建一个新的子索引。
PG13.12修复在所有分区被附加后标记分区索引为有效时可能出现的失败,在更新索引的pg_index条目时,可能会使用其他列的过时数据。一种报告的症状是“尝试更新不可见元组”错误。
PG13.12避免为伪常数连接子句的外键关联生成不正确的计划,计划器目前不支持在推送下降的远程连接中附加伪常数连接子句的支持,因此在这种情况下禁用生成远程连接。
PG13.12在展开规则动作时,正确处理RLS策略表达式和安全屏障视图中的子选择
PG13.12在ALTER TABLE ATTACH PARTITION期间,将分区索引与子索引进行匹配时忽略无效的子索引,此类索引现在将被忽略,而会创建一个新的子索引。
PG13.12修复在所有分区都被附加后标记分区索引为有效时可能失败的问题
PG13.12修复ALTER EXTENSION SET SCHEMA,如果扩展包含扩展模式之外的任何对象,则会报错
PG13.12修复具有内部哈希键的哈希连接,其中哈希键包含来自外部嵌套循环的参数,当这些参数的值更改后重新扫描连接时,我们必须重建哈希表,但忽略了这一点。这可能导致遗漏连接输出行
PG13.12允许在检测到某些类型的B树索引损坏后继续进行VACUUM,如果检测到无效的兄弟页链接,则记录问题并继续进行,而不像以前那样抛出错误。除了REINDEX外,没有其他方法可以修复损坏的索引,但在执行此操作之前阻止VACUUM完成可能会使情况变得更糟。确保在VACUUM检测到pg_database.datfrozenxid或pg_database.datminmxid中的无效数据后释放WrapLimitsVacuumLock
PG13.12在崩溃恢复期间避免二阶段事务的重复重放,在完成部分检查点时发生崩溃,并且此检查点已经将某些二阶段事务状态数据刷新到磁盘时,崩溃恢复可能会尝试两次重新播放准备好的事务,导致一个致命错误,例如启动过程中的“锁定已被持有”。
PG13.12确保创建未记录索引的init fork被WAL记录,虽然未记录索引的主数据fork不会被WAL记录,但其init fork应该,以确保在崩溃后我们有一个一致的状态可供还原索引。如果init fork不包含任何数据,则会漏掉此步骤,而这是任何标准索引AM都不会使用的情况;但也许某些扩展会这样行为
PG13.12修复对延迟检查点结束标志的漏重新初始化,这可能导致检查点不必要的延迟,或在启用断言的构建中导致断言失败。
PG13.12加强contrib/hstore输入中的空格检查,在某些情况下,字符可能会被错误地识别为空格,因此被丢弃。

PG13.13

版本号BUG FIXED/功能更新
PG13.13阻止对区间列的 btree 索引条目去重
PG13.13修复带有多个分区键的哈希分区表的分区步骤生成和运行时分区修剪问题,在某些情况下,针对其中一个分区键的 IS NULL 条件可能导致崩溃
PG13.13避免对 to_tsvector() 的长输入进行过早的内存分配失败
PG13.13改进对损坏的 PGLZ 压缩数据的检查
PG13.13避免在 EXPLAIN 中崩溃,如果一个标记为 EXPLAIN 显示的参数在启动时为 NULL
PG13.13避免在相关 SQL 函数中撕裂读取 pg_control,在读取 pg_control 之前获取适当的锁,以确保我们获得该文件的一致视图
PG13.13修复 ANALYZE 在继承表上的进度统计数据短暂显示不一致的问题
PG13.13跟踪缓存 CALL 语句的依赖关系,并在需要时重新计划它们,DDL 命令(如替换已内联到 CALL 参数中的函数)可能会导致需要重新计划已被 PL/pgSQL 缓存的 CALL。然而,这没有发生,导致了误行为或奇怪的错误,如 “缓存查找失败”。
PG13.13在读取 WAL 时,将内存不足错误视为致命错误,以前,这会被视为伪数据情况,导致错误地认为我们已到达 WAL 的末尾,这可能导致 WAL 重放不一致。
PG13.13修复由于尝试根据伪造的 WAL 记录长度字段分配内存而可能导致的恢复失败
PG13.13增加对 LLVM 16 和 17 的支持

PG13.14

版本号BUG FIXED/功能更新
PG13.14加强 REFRESH MATERIALIZED VIEW CONCURRENTLY 的安全限制,并发刷新命令的一个步骤是在较弱的安全限制下运行的。如果物化视图的所有者能够说服超级用户或其他高特权用户对该视图执行并发刷新,那么该视图的所有者可能会控制以运行 REFRESH 的用户权限执行的代码。修复使得所有用户确定的代码都按照预期以视图所有者的身份运行。
PG13.14修复执行 JIT 内联时的内存泄漏问题,有多份报告称,后端进程在进行了足够多的 JIT 编译后会出现内存不足的情况。此修复应能解决该问题
PG13.14避免生成不正确的分区连接计划,涉及横向引用的一些罕见情况可能会生成不正确的计划。受影响的查询可能会产生错误的结果,或出现诸如“在子计划目标列表中找不到变量”或执行器崩溃等奇怪的错误。
PG13.14修复在 PlaceHolderVars 中错误包装子查询输出表达式的问题,此修复解决了在子查询位于外连接下方且其输出列横向引用了外连接范围外的内容时产生错误结果的问题。由于外连接的作用,输出列在应为 NULL 时可能不会显示为 NULL。
PG13.14避免在并行哈希连接中请求过大的共享内存区域,限制值过大,可能导致在预期哈希表大小足够大时出现“无效的 DSA 内存分配请求大小”错误。
PG13.14修复在复杂继承树上执行 ALTER TABLE ADD COLUMN 时可能发生的故障
PG13.14在执行 DROP STATISTICS 时正确锁定相关表,如果在 DROP 与 ANALYZE 并发执行时未能获得锁,可能会导致“元组被同时删除”错误。
PG13.14让 pg_file_settings 视图检查具有后端或超级用户后端上下文的设置中未应用值的有效性
PG13.14修复清理 GIN 索引内部页面的不完整分割时的锁定不足问题
PG13.14避免在 GIN 索引插入过程中过早释放缓冲区固定,如果索引根页面的分裂与我们的插入操作同时发生,代码可能会因为“缓冲区 NNNN 不属于资源所有者”而失败。
PG13.14在新客户端断开连接而未响应服务器的密码挑战时返回正确的状态代码
PG13.14修复 libpq 在两个不同线程中并发初始化 OpenSSL 支持时的竞争条件
PG13.14在 pg_dump 中,不要转储扩展成员对象的 RLS 策略或安全标签

PG13.15

版本号BUG FIXED/功能更新
PG13.15修复多行 VALUES 语句插入到作为数组或复合类型域的目标列中的问题,这些情况下,要么会因数据类型不匹配而出乎意料地失败,要么会插入意外的强制转换,可能导致奇怪的结果。
PG13.15修复在表按布尔列分区且查询包含布尔 IS NOT 子句时,错误修剪 NULL 分区的问题,NULL 值满足类似 boolcol IS NOT FALSE 的子句,因此剪除包含 NULL 的分区会产生不正确的结果
PG13.15使 ALTER FOREIGN TABLE SET SCHEMA 操作能够将任何拥有的序列移入新模式
PG13.15避免删除孤立临时表时发生死锁,如果创建临时表的会话在删除表之前崩溃,autovacuum 将最终尝试删除孤立表。然而,被分配到相同临时命名空间的会话也会这么做。如果临时表有依赖项(如拥有的序列),这两次清理尝试之间可能会发生死锁。
PG13.15避免检查每个关系的冻结 XID 值时的竞态条件,VACUUM 从每个关系值计算每个数据库的冻结 XID 值时,可能会因另一个 VACUUM 同时更新这些值而混淆。
PG13.15禁止在正在使用的外部 SQL 命令中将表转换为视图
PG13.15修复在“请求的统计类型 X 尚未构建”错误消息中错误报告的统计类型代码
PG13.15在 FROM 子句中使用返回 RECORD 类型的函数时更加小心,此类函数调用的输出列必须由指定列名和数据类型的 AS 子句定义。如果实际函数输出值不匹配,应在运行时抛出错误。然而,一些代码路径会过早检查实际值,并可能在不匹配预期时发出奇怪的错误或遭遇断言失败。
PG13.15修复 XID 状态函数中旧事务 ID 的检测,超过 2^31 事务之前的事务 ID 可能会被误认为是最近的,从而导致 pg_xact_status() 或 txid_status() 的错误行为。
PG13.15在重新索引时访问索引抛出错误,以前这只是一个断言检查,但现在已升级为常规运行时错误。当重新索引一个试图访问其自身表的用户定义索引表达式时,这将提供更准确的错误消息。
PG13.15确保仅索引扫描 name 列返回一个完全填充的值索引中物理存储的值被截断,先前返回给调用者的是该值的指针。这在 valgrind 下测试时会引发投诉。理论上,这可能导致崩溃,尽管目前尚无报告。
PG13.15修复 pg_dumpall,以便在存在角色注释时,无论 --no-role-passwords 的设置如何,都会进行转储
PG13.15在 contrib/postgres_fdw 中,避免发出按常量排序的请求,这可能出现在涉及 UNION ALL 和常量生成子查询的情况下。按常量排序不仅无用,还可能被远程服务器误解,导致“ORDER BY position N is not in select list”错误。



置顶文章

撕逼! PostgreSQL 和 MongoDB 开撕,MySQL却躺枪

PostgreSQL  哪些版本尽量避免使用,版本更新重点明晰(PG12)

PostgreSQL  15 16 小版本更新信息小结 版本更新是不是挤牙膏

PostgreSQL 14 小版本分析,有那个版本不建议使用

Windows 是MySQL和PostgreSQL高性能数据库的坟墓

PostgreSQL 具有createdb的用户无法创建数据库的原因(之一)



往期热门文章:

PostgreSQL 同样的语句 一会快 一会慢到底怎么回事,
MongoDB  系统IOPS 告警系统处于崩溃,优化语句从1秒优化到1毫秒解决问题
云原生数据库是青出于蓝胜于蓝,还是数据库产品的倒退?
专访唐建法-从MongoDB中国第一人到TapData掌门人的故事
MySQL 8.0x 到 9.0均可能崩溃--云厂商开发指责 MYSQL不测试就推新版本?
DISS 阿里云 DAS数据库服务,阿里云数据库服务的毒瘤

临时工说:DBA 7*24H 给2万的工作,到底去不去?

PolarDB 最近遇到加字段加不上的问题 与 使用PolarDB 三年感受与恳谈

PostgreSQL 稳定性平台 PG中文社区大会--杭州来去匆匆

MySQL 让你还用5.7 出事了吧,用着用着5.7崩了

临时工访谈:问金融软件开发总监  哪些业务不用传统数据库
PolarDB  Serverless POC测试中有没有坑与发现的疑问
临时工访谈:PolarDB Serverless  发现“大”问题了  之 灭妖记 续集
临时工访谈:庙小妖风大-PolarDB 组团镇妖 之 他们是第一
PolarDB for PostgreSQL  有意思吗?有意思呀
PolarDB  Serverless POC测试中有没有坑与发现的疑问

MySQL 的SQL引擎很差吗?由一个同学提出问题引出的实验

临时工访谈:从国产数据库 到 普罗大众的产品 !与在美国创业软件公司老板对话

PostgreSQL 如何通过工具来分析PG 内存泄露

MySQL 的SQL引擎很差吗?由一个同学提出问题引出的实验
临时工访谈:我很普通,但我也有生存的权利,大龄程序员 求职贴
临时工说: 快速识别 “海洋贝壳类” 数据库方法速递
临时工说:国产 数据库 销售人员  图鉴
临时工说:DBA 是不是阻碍国产数据库发展的毒瘤 ,是不是?从国产
PostgreSQL   玩PG我们是认真的,vacuum 稳定性平台我们有了
临时工说:裁员裁到 DBA 咋办  临时工教你 套路1 2 3
PolarDB  搞那么多复杂磁盘计费的东西,抽筋了吗?
临时工说:OceanBase 到访,果然数据库的世界很卷,没边
MONGODB  ---- Austindatabases  历年文章合集
MYSQL  --Austindatabases 历年文章合集
POSTGRESQL --Austindatabaes 历年文章整理
POLARDB  -- Ausitndatabases 历年的文章集合
PostgreSQL  查询语句开发写不好是必然,不是PG的锅
SQL SERVER 如何实现UNDO REDO  和PostgreSQL 有近亲关系吗
MongoDB 2023纽约 MongoDB 大会 -- 我们怎么做的新一代引擎 SBE Mongodb 7.0双擎力量(译)
MongoDB 2023年度纽约 MongoDB 年度大会话题 -- MongoDB 数据模式与建模
MongoDB  双机热备那篇文章是  “毒”
MongoDB   会丢数据吗?在次补刀MongoDB  双机热备
临时工说:从人性的角度来分析为什么公司内MySQL 成为少数派,PolarDB 占领高处
POLARDB  到底打倒了谁  PPT 分享 (文字版)
PostgreSQL  字符集乌龙导致数据查询排序的问题,与 MySQL 稳定 "PG不稳定"
PostgreSQL  Patroni 3.0 新功能规划 2023年 纽约PG 大会 (音译)

Austindatabases 公众号,主要围绕数据库技术(PostgreSQL, MySQL, Mongodb, Redis, SqlServer,PolarDB, Oceanbase 等)和职业发展,国外数据库大会音译,国外大型IT信息类网站文章翻译,等,希望能和您共同发展。



AustinDatabases
关于数据库相关的知识分享
 最新文章