近年来，随着分布式数据库逐渐成为业界主流的技术方向之一，使用分布式架构仿佛即代表了技术先进性，而这种观点也十分契合大数据时代的海量数据需求。但是，在“账务类”业务场景下，是否也必须使用分布式架构呢？对此，业界充斥着截然不同的两种声音。
PostgreSQL 的流复制自引入以来以稳定著称，近几年的几个大版本陆续完成了好几个大特性，例如
可视化空间数据是一项重要任务。在本教程中，您将学习如何使用PostGIS和QGIS快速可视化OpenStreetMap（OSM）数据。这样做的想法是让您尽快入门，并充分利用您的数据
摘要 总所周知，阿里云的 PostgreSQL 和 HybridDB for PostgreSQL 和 oss 是全面互通的。 HybridDB for PostgreSQL 由于是 MPP 架构天生包括多个计算节点，能够以为并发的方式读写 oss 上的数据。PostgreSQL 在这方面要差一点，默认情况下只能单进程读写 OSS，不过通过 dblink 的加持，我们也能让 OSS 中的数据快速装载到 PostgreSQL。本文就给大家讲讲这其中的黑科技。
背景 在常见的PostgreSQL双节点高可用构架中，如果主库挂了且主备无延迟，高可用系统会提升老备库为新主库对外服务。而对于老主库，则可以有很多处理策略，例如： 删掉，重搭新备库。 降级为备库，继续服务。 很显然，相比来说第一种不是个很好的方案。当数据量比较大时，重搭备库的时间成本太高，系统的可用性降低。但是因为老的主库挂掉的原因多种多样，甚至有可能是高可用系统的误判，而老主库也有可能是在挂掉之后又重新作为主库启动起来，这个时候降级并重搭流复制关系的操作就有可能失败（新的备库比新主库数据更超前）。 为了解决这种情况，PostgreSQL 引入了pg_rewind工具。
监控工作做得不好，出了问题就要背锅，这是我们运维人员多年血泪换来的教训。还记得好几个月前， XXX运营商出了一个重大故障，从故障发生到分析定位花费了几个小时，当时一群人扑向故障，最终在某个人的灵光一现下找到了问题的原因。
由于在Barman 2.11中引入了新的实用程序barman-cloud-restore和barman-cloud-wal-restore，现在可以使用以前使用的barman-cloud-wal-archive和 barman-cloud-backup命令执行的完全备份来执行PostgreSQL实例的恢复。在下一篇文章中，我们一起探索如何实现这一点。
目前PG的native partition分区性能还有优化空间，一种解决方法是使用pg_pathman插件，另一种方法是业务上直接插分区，还有一种方法是使用UDF函数接口（函数内部使用prepared statement来降低PARSE CPU开销）。 本文提供的是UDF的例子，以及性能比对。
本周开始，苹果开始使用他们自己的芯片交付Mac，首先是命名为M1的Mac SOC。M1使用ARM指令集，并声称在媒体工作负载方面有惊人的加速[校对注1]。 我想知道它运行PostgreSQL效果如何--PostgreSQL在各种ARM系统上运行多年的应用程序。结果太好了！
就像与大多数数据库一样，在PostgreSQL中，触发器是一种自动响应事件的方法。也许您想在插入表数据的时候运行函数。也许您想要审计数据的删除，或者只是响应一些UPDATE语句。这正是触发器的好处。这篇文章是对PostgreSQL中触发器的一般性介绍，对于那些想要开始编程的人们来说这是一个简单的教程。
在上一篇关于pgBackRest的文章中，我们了解了如何安装和设置pgBackRest，并且为PostgreSQL进行一次备份。这是一个非常基本的单服务器设置，只是为了掌握该工具的窍门。在生产环境中不推荐使用这种操作，因为不建议在运行数据库的同一服务器上执行备份（或者说不起作用）。
背景 假设我们有一些物体的轨迹数据（经纬度、measure(通常存为epoch时间戳)），比如车辆、人、传感器等。 给定一个物体在某个时间范围的轨迹数据，查找有没有与这个物体接触的轨迹，并按亲密度排序。
自9.4版以来，PostgreSQL中一个有趣的特性是能够使用复制插槽控制WAL文件的删除。不好的一面是，复制槽可能会导致磁盘被旧的WAL填满，从而导致主生产服务器死亡。在本文中，我将解释PostgreSQL复制槽，以及PostgreSQL 13中的一个新特性如何帮助防止这个问题。
背景 imgsmlr是PostgreSQL的一款支持以图搜图的插件， 支持 1、几种图像特征值数据类型， 2、图像特征值相似算子， 3、图像特征值相似排序索引支持， 4、图像相似排序的索引（通过扩展GiST索引接口实现）支持， 5、png,gif等图像格式特征值提取函数。
背景 1、PG物理流复制的从库，当激活后，可以开启读写，使用pg_rewind可以将从库回退为只读从库的角色。而不需要重建整个从库。 2、当异步主从发生角色切换后，主库的wal目录中可能还有没完全同步到从库的内容，因此老的主库无法直接切换为新主库的从库。使用pg_rewind可以修复老的主库，使之成为新主库的只读从库。而不需要重建整个从库。 3、如果没有pg_rewind，遇到以上情况，需要完全重建从库。或者你可以使用存储层快照，回退回脑裂以前的状态。又或者可以使用文件系统快照，回退回脑裂以前的状态。
当我们谈论数据库安全性时，它包含了不同领域的不同模块。这是一个非常广泛的话题，因为对于数据库，我们需要保护整个生态系统，而不仅仅是数据库节点。下图显示了需要保护的且容易出现故障的部分。很明显，数据库本身只是其中的六分之一。您需要保护您的（1）网络（2）网络节点（3）数据（4）数据库（5）用户（6）应用程序。一个安全的数据库意味着所有方面都是安全的。
主从复制在保持高可用性方面起着至关重要的作用。服务器故障、操作系统或数据库软件可能需要升级。这就意味着需要重新排列服务器角色、修改复制的指向，同时维护所有数据库之间的数据一致性。 此时必须要更改服务器的拓扑结构，我们可以通过如下不同的方法来实现。
检查点可能是高并发写操作的PostgreSQL主要影响因素。识别这个领域中问题的第一步是监视它们发生的频率，这使得最近在数据库中添加了一个更易于使用的界面。
PostgreSQL中的逻辑复制是一种发布-订阅模型，订阅服务器节点可以订阅发布服务器并实时接收来自发布服务器的逻辑更改。创建订阅时，将在发布服务器节点中生成walsender进程。walsender进程负责逐个读取WAL并重新组合属于每个事务的更改。walsender进程将更改存储在内存中，如果更改超过内存限制，则将其刷新到本地文件。在事务提交时，它对相应的更改进行解码，并将它们发送到订阅服务器，在那里以增量方式应用这些更改。解码后的WAL的传输受网络带宽的限制，用户在应用WAL和赶上发布服务器时会出现延迟。应用侧的这种延迟称为应用延迟。
临时表特性已经存在了很长时间，并且被应用程序开发者广泛使用。但是，临时表的功能远远超出了您的了解。PostgreSQL允许您很好地配置临时表的期限，并帮助避免一些常见的陷阱。