暂无图片
暂无图片
暂无图片
暂无图片
暂无图片

PostgreSQL一周快报(2021年8月8日)

 一

PostgreSQL   行业新闻


PGConf NYC 将于 2021 年 12 月 3 日至 4 日举行。


 二

PostgreSQL 产品新闻

01


Pgpool-II 4.2.4, 4.1.8, 4.0.15, 3.7.20 and 3.6.27,发布PostgreSQL的连接池和语句复制系统。


02


pgmoneta 0.4.0,发布PostgreSQL 备份和恢复系统。

03


PostgreSQL项目发布持续集成系统Buildfarm 13.1软件。


04


dbForge Schema Compare 1.2 for PostgreSQL。

05


pg_timetable 4.0.0,发布PostgreSQL 的作业调度器。





 三

PostgreSQL 新  闻


Planet PostgreSQL:
https : planet.postgresql.org/

 四

PostgreSQL 应用补丁

01

Amit Kapila pushed


修复 021_twophase.pl 中的测试失败。
该测试期望与两个订阅相对应的两个准备好的事务,但它等待仅赶上一个订阅。通过允许等待两个订阅来修复它。
Reported-by:Michael Paquier, as per buildfarm 
Author: Ajin Cherian 
Reviewed-By: AmitKapila, Vignesh C, Peter Smith Discussion: https://postgr.es/m/CAA4eK1+_0iNQ8Z=KVTjmmAqNX-hyv+1+fnZ-Yx8CVP=uAcekqw@mail.gmail.com 
https://git.postgresql.org/pg/commitdiff/eaf5321c352478266cebe2aa50ea4c34a8fdd2c7
 
为逻辑复制中的流事务添加准备 API 支持。
Commit a8fd13cab0 通过订阅的新选项“two_phase”为内置逻辑复制添加了对准备好的事务的支持。现有流选项不允许使用“two_phase”选项。
此提交允许“流”和“双相”订阅选项的组合。它扩展了 pgoutput 插件和订阅者端代码,为流交易添加了准备 API,这将应用准备时在假脱机文件中累积的更改。
Author: Peter Smith and Ajin Cherian 
Reviewed-by: Vignesh C, AmitKapila, Greg Nancarrow 
Tested-By: Haiying Tang
Discussion: https://postgr.es/m/02DA5F5E-CECE-4D9C-8B4B-418077E2C010@postgrespro.ru 
Discussion: https://postgr.es/m/CAMGcDxeqEpWj3fTXwqhSwBdXd2RS9jzwWscO-XbeCfso6ts3+Q@mail.gmail.com 
https://git.postgresql.org/pg/commitdiff/63cf61cdeb7b0450dcf3b2f719c553177bac85a2
 

02

Etsuro Fujita pushed


修复提交1ec7fca8592178281cd5cdada0f27a340fb813fc 中的疏忽。
我没有考虑到当 ExecAppendAsyncEventWait() 使用 postgres_fdw 通知多个具有异步能力的节点时,前一个节点可能调用 process_pending_request() 来处理由后继节点发出的挂起异步请求的可能性。
在这种情况下,后续节点应该生成一个元组,以便在收到通知时从 process_pending_request() 获取的元组返回到父 Append 节点。维修每个 buildfarm 通过 Michael Paquier。
回补丁到 v14,就像之前的提交一样。感谢 Tom Lane 进行测试。
Discussion: https://postgr.es/m/YQP0UPT8KmPiHTMs%40paquier.xyz 
https://git.postgresql.org/pg/commitdiff/a8ed9bd59d48c13da50ed2358911721b2baf1de3
 
postgres_fdw:修复外部表中生成的列的问题。
postgres_fdw 将远程表中的生成列作为普通列导入,并导致在插入外部表时出现“错误:无法将非DEFAULT 值插入列“foo”之类的失败,因为它试图将值插入到生成的列中。
为了解决这个问题,我们假设 postgres_fdw 外部表中的生成列被定义,以便它们代表底层远程表中的生成列:* 在插入或更新时将生成列的 DEFAULT 发送到外部服务器,而不是生成在本地服务器上计算的列值。 
向 postgresImportForeignSchema() 添加一个选项“import_generated”,以在从外部服务器导入的外部表的定义中包含列生成的表达式。
该选项默认为 true。该假设似乎是合理的,因为这将查询 postgres_fdw 外部表,返回与生成的表达式一致的生成列的值。
在这里,修复 postgresImportForeignSchema() 中的另一个问题:当启用import_default 选项时,它尝试将列生成的表达式作为列默认表达式包含在外部表定义中。
根据Daniel Cherniy 的错误 #16631。回补到v12,其中添加了生成的列。
Discussion: https://postgr.es/m/16631-e929fe9db0ffc7cf%40postgresql.org 
https://git.postgresql.org/pg/commitdiff/aa769f80ed80b7adfbdea9a6bc267ba4aeb80fd7
 

03

AndresFreund pushed


从 AuxiliaryProcessMain() 中删除错位的注释。
至少从626eb021988 起,该评论就不再有意义了。由于它实际上并没有解释任何内容,只需将其删除即可。
Author:Andres Freund andres@anarazel.de 
https://git.postgresql.org/pg/commitdiff/8b1de88b7ce9fe0458d3950121a797fd3d988f6c
 
pgstat:拆分报告/获取bgwriter 和 checkpointer 统计信息。
由于bgwriter 和 checkpointer 在806a2aee379 中被分成两个进程,因此这些已经无关紧要。由于有几个挂起的补丁(共享内存统计信息,扩展了一组跟踪的 IO/缓冲区统计信息)通过分组变得更加尴尬,因此将它们拆分。
单独完成以使审查更容易。这并不会改变pg_stat_bgwriter或移动字段的内容进行bgwriter checkpointer的统计信息可以说是不属于任一。
然而 pgstat_fetch_global() 被重命名并拆分为 pgstat_fetch_stat_checkpointer() 和pgstat_fetch_stat_bgwriter()。
Discussion: https://postgr.es/m/20210405092914.mmxqe7j56lsjfsej@alap3.anarazel.de 
https://git.postgresql.org/pg/commitdiff/1bc8e7b0991c1eae5fa6dc2d29bb2280efb52740
 
pgbench:使用流水线时,仅在必要时执行 PQconsumeInput()。
到目前为止,我们为每个流水线查询都做了一个 PQconsumeInput(),要求操作系统提供更多输入——它通常不会有,因为所有结果可能已经发送。
事实证明,这会对性能产生显着影响。Alvaro Herrera 回顾了添加 PQisBusy() 检查的想法,但不是这个具体的补丁。
Author:Andres Freund andres@anarazel.de 
Discussion: https://postgr.es/m/20210720180039.23rivhdft3l4mayn@alap3.anarazel.de Backpatch:14, where libpq/pgbench pipelining was introduced. 
https://git.postgresql.org/pg/commitdiff/87bff68840d542011ed8f60427502fb90fdf2873
 
进程启动:将 postmaster 的 --forkboot 重命名为 --forkaux。
考虑到 bootstrap 模式不能在 postmaster 下运行,aux 进程以 --forkboot 启动是令人困惑的。
Author:Andres Freund andres@anarazel.de 
Reviewed-By: KyotaroHoriguchi horikyota.ntt@gmail.com 
Reviewed-By: RobertHaas robertmhaas@gmail.com 
Discussion: https://postgr.es/m/20210802164124.ufo5buo4apl6yuvs@alap3.anarazel.de 
https://git.postgresql.org/pg/commitdiff/50017f77722b8b998ead5ca6fdb0b821fe7a34d2
 
进程启动:将 BootstrapModeMain 与 AuxiliaryProcessMain 分开。
一旦所有的 if 都被删除,两者之间几乎没有共享代码。令人困惑的是,辅助进程实际上并不是通过在main() 中调用 AuxiliaryProcessMain() 来启动的。
还有更多事情要做,AuxiliaryProcessMain() 应该移出 bootstrap.c,并且 BootstrapModeMain() 不应该使用/成为 AuxProcType 的一部分。
Author:Andres Freund andres@anarazel.de 
Reviewed-By: KyotaroHoriguchi horikyota.ntt@gmail.com 
Reviewed-By: RobertHaas robertmhaas@gmail.com 
Discussion: https://postgr.es/m/20210802164124.ufo5buo4apl6yuvs@alap3.anarazel.de 
https://git.postgresql.org/pg/commitdiff/5aa4a9d2077fa902b4041245805082fec6be0648
 
进程启动:auxprocess:reindent 块。保持分开以便于审查,特别是因为 pgindent 坚持重排一些评论。
Author:Andres Freund andres@anarazel.de 
Reviewed-By: KyotaroHoriguchi horikyota.ntt@gmail.com 
Reviewed-By: RobertHaas robertmhaas@gmail.com 
Discussion: https://postgr.es/m/20210802164124.ufo5buo4apl6yuvs@alap3.anarazel.de 
https://git.postgresql.org/pg/commitdiff/27f790346621e1db3cc0305e7ae2b2cbfb537aa6
 
进程启动:将 AuxiliaryProcessMain 移动到它自己的文件中。在前面的提交之后,auxprocess代码独立于 bootstrap.c - 因此专用文件似乎不那么令人困惑。
Author:Andres Freund andres@anarazel.de 
Reviewed-By: KyotaroHoriguchi horikyota.ntt@gmail.com 
Reviewed-By: RobertHaas robertmhaas@gmail.com 
Discussion: https://postgr.es/m/20210802164124.ufo5buo4apl6yuvs@alap3.anarazel.de 
https://git.postgresql.org/pg/commitdiff/0a692109dcc73178962069addf7478ac89950e4d
 
进程启动:从 AuxProcType 中删除引导程序/检查器模式。
两者实际上都没有初始化为辅助进程,因此为它们保留 PGPROC 等实际上没有意义。这通过在引导模式中途退出来保持检查器模式。
这在某些时候可能值得改变,也许如果我们将检查器模式扩展为更通用的工具。
Author:Andres Freund andres@anarazel.de 
Reviewed-By: KyotaroHoriguchi horikyota.ntt@gmail.com 
Reviewed-By: RobertHaas robertmhaas@gmail.com 
Discussion: https://postgr.es/m/20210802164124.ufo5buo4apl6yuvs@alap3.anarazel.de 
https://git.postgresql.org/pg/commitdiff/f8dd4ecb0b7fc3420e199021375e622815cd326f
 
进程启动:集中 pgwin32_signal_initialize() 调用。一方面,现有位置导致main() 中的代码有些尴尬。另一方面,新位置无论如何更容易理解。
Author:Andres Freund andres@anarazel.de 
Reviewed-By: KyotaroHoriguchi horikyota.ntt@gmail.com 
Reviewed-By: RobertHaas robertmhaas@gmail.com 
Discussion: https://postgr.es/m/20210802164124.ufo5buo4apl6yuvs@alap3.anarazel.de 
https://git.postgresql.org/pg/commitdiff/07bf37850991c68a7038fb06186bddfd64c72faf
 
也在 postmaster 中调用 pgwin32_signal_initialize() 。
这是 07bf3785099 中的疏忽。虽然它确实减少了由于提交而带来的简化的好处,但对我来说似乎仍然是一个胜利。
在 miscinit.c 中为 postmaster 设置一个镜像 InitPostmasterChild() InitStandaloneProcess() 函数似乎是一个好主意,以便更容易地在三个可能的环境之间保持初始化同步。
Author:Andres Freund andres@anarazel.de 
Discussion: https://postgr.es/m/20210805214109.lzfk3r3ae37bahmv@alap3.anarazel.de 
https://git.postgresql.org/pg/commitdiff/0de13bbc47d19c95de132cc85c341fdab079c170
 
进程启动:总是在 BaseInit() 之前调用 Init[Auxiliary]Process()。
对于 EXEC_BACKEND InitProcess()/InitAuxiliaryProcess() 需要在我们调用 BaseInit() 之前被很好地调用,因为 SubPostmasterMain() 需要 LWLocks 才能工作。
由于平台之间的初始化顺序不同,因此不必要地难以理解系统并为新子系统添加初始化点而不会出现大量重复。为了能够更改顺序,BaseInit() 不能再触发CreateSharedMemoryAndSemaphores() - 显然这需要在我们调用InitProcess() 之前发生。
无论如何,在单用户/引导模式下显式创建共享内存似乎更干净。在此更改之后,将 bufmgr 初始化分离为 InitBufferPoolAccess() InitBufferPoolBackend() 不再有意义,因此删除了后者。
Author:Andres Freund andres@anarazel.de 
Reviewed-By: KyotaroHoriguchi horikyota.ntt@gmail.com 
Discussion: https://postgr.es/m/20210802164124.ufo5buo4apl6yuvs@alap3.anarazel.de 
https://git.postgresql.org/pg/commitdiff/b406478b87e2234c0be4ca4105eee3bb466a646b
 
pgstat:在 BaseInit() 中调用 pgstat 以修复 AV 对 pgstat的未初始化使用。
以前在 InitPostgres() 和AuxiliaryProcessMain() 中调用了 pgstat_initialize()。事实证明,至少有一种情况我们在调用 pgstat_initialize() 之前报告了统计信息,请参阅AutoVacWorkerMain() 有意提前调用 pgstat_report_autovac()。
这对于当前的 pgstat 实现来说不是问题,因为 pgstat_initialize() 只注册一个关闭回调。但是在基于共享内存的 stats 实现中,我们正在努力 pgstat_initialize() 必须做更多的工作。
在 b406478b87e BaseInit() 之后是一个中心位置,可以放置普通后端和辅助后端共享的初始化。显然 BaseInit() 在 InitPostgres() 注册 ShutdownPostgres 之前被调用。
以前 ShutdownPostgres 是第一个 before_shmem_exit 回调,现在通常是 pgstats。那应该没问题。以前 pgstat_initialize() 在引导模式下没有被调用,但似乎没有必要这样做。现在是无条件完成的。
为了检测这样的未来问题,断言被添加到几个地方,以验证 pgstat 子系统已初始化并且尚未关闭。
Author:Andres Freund andres@anarazel.de 
Discussion: https://postgr.es/m/20210405092914.mmxqe7j56lsjfsej@alap3.anarazel.de 
Discussion: https://postgr.es/m/20210802164124.ufo5buo4apl6yuvs@alap3.anarazel.de 
https://git.postgresql.org/pg/commitdiff/ee3f8d3d3aec0d7c961d6b398d31504bb272a450
 
通过 before_shmem_exit() 完全完成并行工作程序关闭。
这是将统计信息存储在动态共享内存中的一步。由于动态共享内存段在 before_shmem_exit() 回调被处理之后分离,但在on_shmem_exit() 回调之前,在 before_shmem_exit() 回调被处理后无法收集统计信息。
并行工作程序关闭会导致在 DSM 分离回调期间发出统计信息,例如 SharedFileSet(关闭其文件,这会导致 fd.c 发出有关临时文件的统计信息)。
因此并行工作线程关闭需要在 before_shmem_exit回调的处理过程中完成。有人可能认为这个问题可以通过仔细订购 DSM 段的附加来解决,以便 pgstats 段与并行查询段分离。
结果证明这是行不通的,因为 stats 散列可能需要增长,这可能会导致分配新的段,然后将与之前的段分离。有两个代码更改:首先,通过 before_shmem_exit 调用ParallelWorkerShutdown()。
这本身就是一个好主意,因为其他关闭回调如ShutdownPostgres 和 ShutdownAuxiliaryProcess 是通过调用before_*. 其次,显式地从并行查询 DSM 段分离,从而确保在 ParallelWorkerShutdown() 期间发出所有统计信息。这些问题有更好的解决方案,但不清楚哪些解决方案是正确的。
Author:Andres Freund andres@anarazel.de 
Discussion: https://postgr.es/m/20210405092914.mmxqe7j56lsjfsej@alap3.anarazel.de 
Discussion: https://postgr.es/m/20210803023612.iziacxk5syn2r4ut@alap3.anarazel.de 
https://git.postgresql.org/pg/commitdiff/fa91d4c91f28f4819dc54f93adbd413a685e366a
 
使用 before_shmem_exit() 在单用户模式下安排ShutdownXLOG()。
以前使用过 on_shmem_exit()。即将发布的共享内存统计补丁使用 DSM 段来存储统计数据,在 shmem_exit() 中调用 dsm_backend_shutdown() 后无法使用该段。
似乎没有任何理由通过on_shmem_exit() 执行 ShutdownXLOG(),因此更改它。
Author:Andres Freund andres@anarazel.de 
Discussion: https://postgr.es/m/20210405092914.mmxqe7j56lsjfsej@alap3.anarazel.de 
Discussion: https://postgr.es/m/20210803023612.iziacxk5syn2r4ut@alap3.anarazel.de 
https://git.postgresql.org/pg/commitdiff/a1bb3d5dbe6a66ae73d7805a63b951793b5d55df
 
pgstat:通过 before_shmem_exit() 安排每个后端的 pgstat 关闭。
以前使用过 on_shmem_exit()。即将发布的共享内存统计补丁使用 DSM 段来存储统计数据,在 shmem_exit() 中调用 dsm_backend_shutdown() 后无法使用该段。
需要先前的提交才能允许此更改。此提交与共享内存统计信息补丁分开,以便更容易隔离由排序更改引起的问题,而不是存储统计信息的更大更改。
Author:Andres Freund andres@anarazel.de 
Author: KyotaroHoriguchi horikyota.ntt@gmail.com 
Discussion: https://postgr.es/m/20210405092914.mmxqe7j56lsjfsej@alap3.anarazel.de 
Discussion: https://postgr.es/m/20210802164124.ufo5buo4apl6yuvs@alap3.anarazel.de 
Discussion: https://postgr.es/m/20210803023612.iziacxk5syn2r4ut@alap3.anarazel.de 
https://git.postgresql.org/pg/commitdiff/fb2c5028e63589c01fbdf8b031be824766dc7a68
 
将临时文件清理移至 before_shmem_exit()。
正如一些 OSX buildfarm 动物所报告的那样,在 AtProcExit_Files() 处理期间,至少存在一个路径存在临时文件。
由于临时文件清理导致 pgstat 报告,ee3f8d3d3ae 中添加的断言导致失败。这不是 OSX 特定的问题,我们很幸运,OSX 上的计时可靠地触发了问题。导致此问题的已知方法是在使用 MANIFEST 的 perform_base_backup() 期间出现 FATAL 错误 - 在InitializeBackupManifest() 之后添加 elog(FATAL) 可靠地单独重现问题。
问题是在 InitializeBackupManifest() 中创建的临时文件没有通过资源所有者清理进行清理,因为 WalSndResourceCleanup() 目前仅用于非致命错误。
然后允许使用现有的临时文件访问 AtProcExit_Files(),从而导致断言失败。要解决此问题,请将临时文件清理移至 before_shmem_exit() 挂钩并添加断言以确保在初始化/关闭临时文件管理之前/之后不会创建任何临时文件。
最简洁的方法似乎是将 fd.c 初始化分为两部分,一种用于普通文件访问,另一种用于临时文件访问。现在不需要在进程退出期间执行进一步的 fd.c 清理,所以我只是将 AtProcExit_Files() 重命名为 BeforeShmemExit_Files()。
或者,我们可以再次遍历文件以检查是否不存在临时文件,但添加的断言似乎提供了足够的保护。可能结果是在 ee3f8d3d3ae 中添加的断言会引起太多噪音 - 在这种情况下,我们必须将它们降级为警告,至少暂时如此。
此提交不一定是解决此问题的最佳方法,但它应该可以解决 buildfarm 故障。我们可以稍后再修改。
Author:Andres Freund andres@anarazel.de 
Discussion: https://postgr.es/m/20210807190131.2bm24acbebl4wl6i@alap3.anarazel.de 
https://git.postgresql.org/pg/commitdiff/675c945394b36c2db0e8c8c9f6209c131ce3f0a8
 

04

Thomas Munropushed


在崩溃恢复中运行 checkpointer 和 bgwriter。
在崩溃恢复期间启动检查指针和 bgwriter(除了 --single 模式),就像我们在复制时所做的那样。出于谨慎,这并没有在提交 cdd46c76 中完成。
现在,在两种情况下使环境尽可能相似似乎是一个更好的主意。也可能有一些性能优势。
Reviewed-by:Robert Haas robertmhaas@gmail.com 
Reviewed-by: AleksanderAlekseev aleksander@timescale.com 
Tested-by: JakubWartak Jakub.Wartak@tomtom.com 
Discussion: https://postgr.es/m/CA%2BhUKGJ8NRsqgkZEnsnRc2MFROBV-jCnacbYvtpptK2A9YYp9Q%40mail.gmail.com 
https://git.postgresql.org/pg/commitdiff/7ff23c6d277d1d90478a51f0dd81414d343f3850
 
进一步简化 StartupXLOG() 中的一些逻辑。提交7ff23c6d277d1d90478a51f0dd81414d343f3850 给我们留下了两个相同的案例。折叠它们。
Author:Robert Haas robertmhaas@gmail.com 
Discussion: https://postgr.es/m/CA%2BhUKGJ8NRsqgkZEnsnRc2MFROBV-jCnacbYvtpptK2A9YYp9Q%40mail.gmail.com 
https://git.postgresql.org/pg/commitdiff/8f7c8e2bef2bd2587e5d66dd20de15f3db0a6bcb
 

05

Tom Lanepushed


Doc:对逻辑复制协议文档的小幅改进。
在适当的情况下,使用数据类型的后端代码名称注释消息字段数据类型,例如 XLogRecPtr 或 TimestampTz。
以前我们只是说“Int64”,它没有提供太多的信息。还要澄清对对象 OID 的引用,并利用现有约定来表示必须具有固定值的字段的值。
VigneshC, reviewed by Peter Smith and Euler Taveira. Discussion: https://postgr.es/m/CALDaNm0+fatx57KFcBopUZWQpH_tz3WKKfm-_eiTwcXui5BnhQ@mail.gmail.com 
https://git.postgresql.org/pg/commitdiff/a5cb4f9829fbfd68655543d2d371a18a8eb43b84
 
添加各种新的 regexp_xxx SQL 函数。
此补丁添加了新函数 regexp_count()、regexp_instr()、regexp_like() 和 regexp_substr(),并使用一些新的可选参数扩展了regexp_replace()。
所有这些函数都遵循 Oracle 中使用的定义,尽管由于使用我们自己的 regexp 引擎,regexp 语言存在细微差别——最值得注意的是,默认的换行匹配行为是不同的。
类似的函数也出现在 DB2 和其他地方。除了简化可移植性之外,这些函数比我们现有的 regexp_match[es] 函数更容易用于某些任务。
Gilles Darold,heavily revised by me 
Discussion: https://postgr.es/m/fc160ee0-c843-b024-29bb-97b5da61971f@darold.net 
https://git.postgresql.org/pg/commitdiff/6424337073589476303b10f6d7cc74f501b8d9d7
 
不要省略对 typmod -1 的强制转换。
就运行时行为而言,将已经属于具有特定 typmod 的类型的值转换为未指定的 typmod 不会做任何事情。但是,它确实应该更改表达式的公开类型以匹配。
到目前为止,coerce_type_typmod 还没有为此烦恼,这会在递归联合等上下文中产生陷阱。例如,如果联合的一侧是数字(18,3),但它需要是纯数字才能匹配另一侧,则没有直接的方法来表达。
这很容易修复,通过插入 RelabelType 来更新表达式的公开类型。然而,改变这种行为有点紧张,因为它已经存在了很长时间。(我强烈怀疑它' 之所以这样,部分是因为该逻辑早于 7.0 中 RelabelType 的引入。
57b30e8e2 的提交日志消息在这里读起来很有趣。)作为妥协,我们会将更改潜入 14beta3,如果在接下来的三个月内没有出现任何投诉,我们会考虑回补丁到稳定分支。
Discussion: https://postgr.es/m/CABNQVagu3bZGqiTjb31a8D5Od3fUMs7Oh3gmZMQZVHZ=uWWWfQ@mail.gmail.com 
https://git.postgresql.org/pg/commitdiff/5c056b0c2519e602c2e98bace5b16d2ecde6454b
 
真正修复 REFRESH MATERIALIZED VIEW CONCURRENTLY 中的歧义。
与其尝试选择不会与任何可能的用户定义的 matview 列名冲突的表别名,不如调整查询的语法,以便别名仅用于不会被误认为是列名的地方。
大多数情况下,这"alias.*"不仅仅包括编写“别名”,这增加了人类和机器的清晰度。我们确实遇到了"SELECTalias.*" 与“SELECT 别名”不同的问题,但我们可以使用相同的 hack ruleutils.c 用于 SELECT 列表中的整行变量:write "alias.*::compositetype"。
这样做之后,我们不妨恢复到原来的别名;它们更容易阅读。像 75d66d10e 一样,回补丁到所有支持的分支。
Discussion: https://postgr.es/m/2488325.1628261320@sss.pgh.pa.us 
https://git.postgresql.org/pg/commitdiff/9179a82d7af38112cd0f6e84ab62d0b3592a6e0e
 
使regexp引擎与backref相关的编译状态更具防弹性。 
到目前为止,我们通过存储一个指向关联的sube节点的指针来记住capturing parenthesis subexpression的定义。 
这在以前是可以的,因为在解析regexp的其余部分时,不会再修改该subRE。 然而,在提交ea1268f63之后,情况就不再是这样了:parseqatom()的外部调用feels free to scribble onthat subRE  。 
无论如何,这似乎都是可行的,因为我们在“"prepare a general-purpose state skeleton”节中插入子原子的状态实际上与子原子的原始端点在语义上没有什么不同。 但这很容易打破,而且这绝对不是以前的工作方式。 
在此和之前提交中修复的问题之间,似乎最好完全摆脱这种对subRE节点的依赖。 我们不需要整个子subRE用于将来的回溯,只需要它的开始和结束NFA状态; 让我们存储指向它们的指针。 
此外,在角落的情况下,我们创建了一个额外的子正则来处理立即嵌套的捕获括号,让额外的子正则具有与原始子正则相同的begin/end状态似乎是明智的(s/s2而不是lp/rp)。 
我认为将它从lp链接到rp实际上可能在语义上是错误的,尽管Spencer的原始代码是这样做的,我不能完全确定。 在任何情况下,使用s/s2肯定没有错。
Mark Dilger报道。 回补到v14,有问题的补丁来了。 
Discussion: https://postgr.es/m/0203588E-E609-43AF-9F4F-902854231EE7@enterprisedb.com 
https://git.postgresql.org/pg/commitdiff/cb76fbd7ec87e44b3c53165d68dc2747f7e26a9a
 
修复regexp引擎中“免费后再使用”的问题。 
提交cebc1d34e教会parseqatom()通过去除多余的sube节点来优化分支只包含一个“凌乱的”原子的情况。 
我们真正应该做的是保持为“混乱的”子原子构建子正则; 但是为了避免改变parseqatom的名义API,我让它在将其字段复制到由parsebranch()创建的外部subRE之后删除该节点。 
这在当时似乎是可行的; 但在ea1268f63之后就变得危险了,因为之后的提交允许较低的parse()调用返回一个也被某些v->sub[]条目指向的子正则。 
这意味着我们可能会在v->subs[]中使用一个悬空指针,允许后面的backref出错,但前提是在此期间重用了该sube结构体。 
因此,损害似乎仅限于‘((……))……(……2’这样的情况。 为了解决这个问题,我应该做的是修改parseqatom的API,使它能够删除调用方的子正则而不是被调用方的子正则。 
这样更安全,因为我们知道subRE还没有完成,所以其他地方不会有指向它的指针。
Discussion: https://postgr.es/m/0203588E-E609-43AF-9F4F-902854231EE7@enterprisedb.com 
https://git.postgresql.org/pg/commitdiff/cc1868799c8311ed1cc3674df2c5e1374c914deb
 
重新考虑regexp引擎与backref相关的编译状态。
我在推送了cb76fbd7e之后我立即就懊悔了,因为我发现从数据结构中删除捕获子表达式的子res会破坏我建议的REG_NOSUB优化补丁,恢复该数据结构更改。 
相反,通过不更改端点来解决关于不更改捕获子res端点的问题。 我们不需要,因为那个位元的目的是确保原子有不同于我们连接分支的外部状态对的端点。 
在括号子表达式的情况下,我们已经创建了合适的状态,所以额外的状态是无用的开销。 这似乎比Spencer的原始代码更容易理解,而且它应该也会更快,因为它节省了一些状态创建和弧线更改。 (实际上,我看到Jacobson的web语料库有几个百分点的改进,尽管这只是勉强高于噪音下限,所以我不会对这个结果寄予太多期望。) 
另外,修复ea1268f63添加的逻辑,以确保v->subs[subno]中记录的子句就是capno == subno的子句。Spencer的原始编码记录了捕获节点的子节点,只要考虑到有正确的端点状态,这是可以的,但对于cb76fbd7e,捕获子节点本身也总是有这些端点。
 我认为这种不一致性让REG_NOSUB优化感到困惑。 和以前一样,回补到v14。 
Discussion: https://postgr.es/m/0203588E-E609-43AF-9F4F-902854231EE7@enterprisedb.com 
https://git.postgresql.org/pg/commitdiff/00116dee5ad4c1964777c91e687bb98b1d9f7ea0
 
DOC:删除虚假的 <indexterm> 项目。
显然,665c5855e 中的复制和粘贴。9.6 文档工具链抱怨重复的索引条目,尽管我们的现代工具链没有。无论如何,这些 GUC 肯定不是这些值的默认设置。
https://git.postgresql.org/pg/commitdiff/cf5ce5aa70d33fc3048ab63c50585b8cc0f11dfd
 

06

David Rowleypushed


在 RelOptInfo 中跟踪未修剪分区的位图集。
对于具有大量分区的分区表,其中查询能够修剪除极少数分区之外的所有分区,规划器循环 RelOptInfo.part_rels 检查非空 RelOptInfos 所花费的时间可能会成为整个规划时间的很大一部分. 这里我们添加一个 Bitmapset 来记录未修剪的分区。

这允许我们通过循环 Bitmapset 更有效地跳过修剪的分区。在没有或没有多少分区可以修剪的情况下,这将导致非常轻微的减速,但是,无论如何,这些情况已经很慢了,并且与其他任务(例如路径)相比,循环 Bitmapset 的开销将无法衡量为大量分区创建。
Reviewed-by:Amit Langote, Zhihong Yu Discussion: https://postgr.es/m/CAApHDvqnPx6JnUuPwaf5ao38zczrAb9mxt9gj4U1EKFfd4AqLA@mail.gmail.com 
https://git.postgresql.org/pg/commitdiff/475dbd0b718de8ac44da144f934651b959e3b705
 
在更多的情况下允许有序分区扫描。
959年d00e9d添加附加的能力利用节点代替MergeAppend当我们想要执行的扫描分区表和所需的排序顺序是一样的分区表的分区键和早些时候在这样定义分区只保证包含低阶值 分区。 
但是,以前当有任何分区允许多个Datums时,我们不允许对LIST分区表进行有序分区扫描。 这是一个非常便宜的检查,如果我们检查是否有交错分区,我们可能会做得更好一些,但当时我们没有看到哪些分区被修剪,所以我们仍然可能不允许所有交错分区被修剪的情况。 
自从475dbd0b7以来,我们现在知道了已修剪的分区,我们可以在partitions_are_ordered()中做得更好。 这里我们传递分区剪接到partitions_are_ordered()中幸存下来的分区,对于LIST分区,让它检查是否有任何活动分区也存在于PartitionBoundInfo中定义的新“interleaved_parts”字段中。 
对于RANGE分区,如果存在DEFAULT分区,我们可以放宽导致分区无序的代码。 既然我们现在知道了哪些分区被修剪了,那么当默认分区被修剪时,partitions_are_ordered()现在返回true。 
Reviewed-by:Amit Langote, Zhihong Yu Discussion: https://postgr.es/m/CAApHDvrdoN_sXU52i=QDXe2k3WAo=EVry29r2+Tq2WYcn2xhEA@mail.gmail.com 
https://git.postgresql.org/pg/commitdiff/db632fbca392389807ffb9d9b2207157e8e9b3e8
 
删除未使用的函数声明。
似乎 check_track_commit_timestamp 已声明但从未在我们的代码库中定义。这可能只是原始补丁的开发版本的剩余部分,用于添加提交时间戳。
让我们删除无用的声明。包含 guc.h 似乎也超出了要求。
Author:Andrey Lepikhov 
Discussion: https://postgr.es/m/f49aefb5-edbb-633a-af07-3e777023a94d@postgrespro.ru 
https://git.postgresql.org/pg/commitdiff/75a2d132eaef7d951d
b894cf3201f85e9a524774
 

07

BruceMomjian pushed


doc:添加将 pg_dump 与GNU split 和 gzip 一起使用的示例。这仅适用于GNU split,而不适用于 BSD split 等其他版本。
Reported-by:jim@jdoherty.net Discussion: https://postgr.es/m/162653459215.701.6323855956817776386@wrigleys.postgresql.org Backpatch-through:9.6 
https://git.postgresql.org/pg/commitdiff/cfbbb8610d17bc6d82f37a446c38b29e2a5258f4
 
doc:提到继承的tableoid可以用于分区。
以前在分区文档部分中没有提到 tableoid。我们只有一个链接到继承部分的“所有正常规则”。
Reported-by:michal.palenik@freemap.sk Discussion: https://postgr.es/m/162627031219.693.11508199541771263335@wrigleys.postgresql.org Backpatch-through:10 
https://git.postgresql.org/pg/commitdiff/691272cae96b3c947d3d2d4d8c43c499e72c65a2
 
pg_upgrade:改进关于扩展升级的文档。之前的措辞不清楚升级扩展所需的步骤,以及如何在 pg_upgrade 之后更新它们。
Reported-by:Dave Cramer 
Discussion: https://postgr.es/m/CADK3HHKawwbOcGwMGnDuAf3-U8YfvTcS8jqDv3UM=niijs3MMA@mail.gmail.com Backpatch-through:9.6 
https://git.postgresql.org/pg/commitdiff/5090d709f172ecd00b16b6e336c8c149a3f3d33d
 
pg_upgrade:警告需要更新的扩展。还要创建一个可以运行的脚本来更新它们。
Reported-by:Dave Cramer 
Discussion: https://postgr.es/m/CADK3HHKawwbOcGwMGnDuAf3-U8YfvTcS8jqDv3UM=niijs3MMA@mail.gmail.com Backpatch-through:9.6 
https://git.postgresql.org/pg/commitdiff/e462856a7a559c94bad51507c6b324f337d8254b
 
间隔:溢出到几个月时的舍入值。以前泄漏的大于月的单位被截断为月。还要记录溢出行为。
Reported-by:Bryn Llewelly 
Discussion: https://postgr.es/m/BDAE4B56-3337-45A2-AC8A-30593849D6C0@yugabyte.com Backpatch-through:master
 
C 注释:扩展查询的正确标题。
Reported-by:Justin Pryzby Discussion: https://postgr.es/m/20210803161345.GZ12533@telsasoft.com Backpatch-through:9.6 
https://git.postgresql.org/pg/commitdiff/9e51cc87fd0ac46b183cb7302a6751d52d3f159a
 

08

PeterGeoghegan pushed


使vacuum_index_cleanup reloption RELOPT_TYPE_ENUM
对提交 3499df0d 的监督,它将 reloption 概括为一种为用户提供一种始终避免 VACUUM 的索引绕过优化的方法。根据 Nikolay Shaplov 的名单外报告。
Backpatch: 14-,索引清理reloption 被扩展。
https://git.postgresql.org/pg/commitdiff/cc8033e1dafe89271aa86c2f2f86a828956929f0
 

09

Dean Rasheedpushed


使用“EEEE”格式修复 to_char() 中的除以零错误。
这修复了使用 to_char() 以科学记数法格式化数值时的长期错误——如果值的指数小于 -NUMERIC_MAX_DISPLAY_SCALE-1 (-1001),则会产生除以零错误。
出现此错误的原因是 get_str_from_var_sci() 将其输入除以 10^exp,这是使用 power_var_int() 生成的。
但是,如果结果比例太小,power_var_int()中的下溢测试会导致它返回零。这对于 power_var_int() 唯一的另一个调用方 power_var() 来说不是问题,因为这将 rscale 限制为 1000,但在 get_str_from_var_sci() 中,指数可以小得多,需要更大的 rscale。
通过引入一个新函数来直接计算 10^exp 进行修复,没有 rscale 限制。这也允许更有效地计算 10^exp,而无需任何数字乘法、除法或舍入。
Discussion: https://postgr.es/m/CAEZATCWhojfH4whaqgUKBe8D5jNHB8ytzemL-PnRx+KCTyMXmg@mail.gmail.com 
https://git.postgresql.org/pg/commitdiff/226ec49ffd78c0f246da8fceb3094991dd2302ff
 
调整数字代码中的整数溢出测试。
以前,数字代码通过将较大类型的整数值强制转换为较小类型,然后测试反向转换是否产生原始值来测试较大类型的整数值是否适合较小类型。这完全没问题,只是它导致了 buildfarm 动物 castoroides 的测试失败,很可能是由于编译器错误。
相反,通过与 PG_INT16/32_MIN/MAX 进行比较来进行这些测试。这与其他地方的现有代码相匹配,例如 int84(),它经过了更广泛的测试,因此出错的可能性较小。
同时,添加涵盖数字到int8/4/2 转换的回归测试,并将最近添加的测试调整为 434ddfb79a(在 v11 分支上)的样式,以便更容易诊断故障。
Perbuildfarm via Tom Lane, reviewed by Tom Lane. Discussion: https://postgr.es/m/2394813.1628179479%40sss.pgh.pa.us 
https://git.postgresql.org/pg/commitdiff/2642df9fac09540c761441edd9bdd0a72c62f39c
 

10

Fujii Masaopushed


删除maybe_send_schema() 中未使用的参数“txn”。提交 464824323e 将参数“txn”添加到 may_send_schema() 中,尽管它没有被使用。
Author: HouZhijie 
Reviewed-by: Fujii Masao Discussion: https://postgr.es/m/OS0PR01MB5716146E43928FB92D45D29794EC9@OS0PR01MB5716.jpnprd01.prod.outlook.com 
https://git.postgresql.org/pg/commitdiff/93d573d86571d148e2d14415166ec6981d34ea9d
 

11

PeterEisentraut pushed


修正措辞。
https://git.postgresql.org/pg/commitdiff/05e60aece33e84960ef566e4735b2d93c2d791c8
 
添加缺少的消息标点符号。
 ttps://git.postgresql.org/pg/commitdiff/ba4eb86ceff4eded5920d36ef82a2096db7ad0c0
 
消息样式改进。
https://git.postgresql.org/pg/commitdiff/f4f4a649d80fea3ae0214b06e160eb5d46b48a16
 
pg_amcheck:添加缺少的翻译标记。
https://git.postgresql.org/pg/commitdiff/789d8060f0517d4da0776480d937d8b64d5c5976
 
pg_amcheck:消息样式改进。
https://git.postgresql.org/pg/commitdiff/80dfbbf1b17a1fb1123401799efdc660ee977051
 
删除 T_MemoryContext。这是一个不应定义节点标记的抽象节点。
https : //www.postgresql.org/message-id/flat/c1097590-a6a4-486a-64b1-e1f9cc0533ce@enterprisedb.com
https://git.postgresql.org/pg/commitdiff/256909c6c16797672812fb97678237dfa0d
 
将 NestPath 节点更改为包含 JoinPath 节点。这使得所有 JoinPath 派生节点的结构都相同,与它们是否具有附加字段无关。
讨论: https://www.postgresql.org/message-id/flat/c1097590-a6a4-486a-64b1-e1f9cc0533ce@enterprisedb.com 
https://git.postgresql.org/pg/commitdiff/18fea737b5e47cc677eaf97365c765a47f346763
 
将 SeqScan 节点更改为包含 Scan 节点。这使得所有 Scan 派生节点的结构都相同,与它们是否具有附加字段无关。
讨论:https : //www.postgresql.org/message-id/flat/c1097590-a6a4-486a-64b1-e1f9cc0533ce@enterprisedb.com 
https://git.postgresql.org/pg/commitdiff/2226b4189bb4ccfcc5391ff2486e
 
检查 COPY_POINTER_FIELD 中的大小。而不是让每个调用者都这样做。
讨论:https : //www.postgresql.org/message-id/flat/c1097590-a6a4-486a-64b1-e1f9cc0533ce@enterprisedb.com 
https://git.postgresql.org/pg/commitdiff/c1132aae336c41cf9d35d2232325dcf9d35dc232d
 
删除格式参数中的一些不必要的强制转换。
我们可以直接使用 %zd 或 %zu ,无需转换为int。相反,当一些代码可以直接使用 %d 时,它会抛弃int。 
https://git.postgresql.org/pg/commitdiff/ae03a7c7391dfc59f14226b7cfd8ef9f3390e56f

PostgreSQL认证咨询




往期推荐






开班通知-PCP认证专家(重庆、成都站)培训开班0807

公众号:PostgreSQL考试认证中心开班通知-PCP认证专家(重庆、成都站)培训开班0807

开班通知-PCP认证专家(南京站)培训开班0731

PGCCC,公众号:PostgreSQL考试认证中心开班通知-PCP认证专家(南京站)培训开班0731

PostgreSQL认证专家考试(培训)-北京站-成功举办
PGCCC,公众号:PostgreSQL考试认证中心PostgreSQL认证专家考试(培训)-北京站-成功举办

PCA+PCP认证考试在贵阳成功举办
PGCCC,公众号:PostgreSQL考试认证中心PostgreSQL PCA+PCP认证考试在贵阳成功举办

PCP认证考试(上海站)成功举办
PGCCC,公众号:PostgreSQL考试认证中心PostgreSQL PCP认证考试(上海站)成功举办

PCM认证大师考试(天津站)成功举办
PGCCC,公众号:PostgreSQL考试认证中心PostgreSQL-PCM认证大师考试(天津站)成功举办

PostgreSQL认证考试(武汉站)
公众号:PostgreSQL考试认证中心PostgreSQL认证考试(武汉站)

难考的PostgreSQL认证考试
薛晓刚,公众号:PostgreSQL考试认证中心难考的PostgreSQL认证考试

通知:PostgreSQL证书领取
PGCCC,公众号:PostgreSQL考试认证中心通知:PostgreSQL证书领取

如何在工业和信息化部教育与考试中心查询PostgreSQL证书
PG考试认证中心,公众号:PostgreSQL考试认证中心如何在工业和信息化部教育与考试中心查询PostgreSQL证书


文章转载自PostgreSQL考试认证中心,如果涉嫌侵权,请发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。

评论