就像与大多数数据库一样，在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允许您很好地配置临时表的期限，并帮助避免一些常见的陷阱。
逻辑解码和逻辑复制在PostgreSQL生态中受到了越来越多的关注。这意味着我们需要它与生产HA系统一起很好地工作——但事实证明这存在一个问题。复制槽并没有被同步到备机上，因此主机一旦发生故障，备机升主后，原来的复制槽将不能继续使用。
数据库是现代信息管理系统的核心。它是由一批数据组成的有序集合，能有效地存储和查找数据，常见的操作包括增、删、改、查等等。 通常情况下，数据库中一般都使用了log机制来提升写入的效率。写入数据库的数据，先固化在log中，在之后的某个时间再搬移至真正有序存储数据的地方。每个数据库都有自己的存储数据的机制，常用的包括基于B+树的结构【1】以及基于LSM（log structure merge）树的结构【2】，如图1所示。
ystem_stats扩展是一个存储过程库，允许用户访问用于监控Postgres活动的系统级统计信息。这些过程向数据库服务器显示各种系统度量。 通过使用system stats，可以在数据库监控过程中查看有关系统性能的信息，而无需添加单独的第三方应用程序。EDB已将该扩展开源，并根据PostgreSQL许可证发布了该扩展。
并发控制是多个事务在并发运行时，数据库保证事务一致性（Consistency）和隔离性（Isolation）的一种机制。主流商用关系数据库使用的并发控制技术主要有三种：严格两阶段封锁（S2PL）、多版本并发控制（MVCC）和乐观并发控制（OCC）。本文是PostgreSQL并发控制的第4篇，介绍了在RR（Repeatable Read，可重复读）隔离级别下MySQL和PostgreSQL的异同。
PostgreSQL包含一个变化的事件范围，它实际上在当前事务id之前或之后大约20亿个事务。当前事务id前面超过20亿或后面超过20亿的事务被认为是未来的事务，因此对当前事务是不可见的。 PostgreSQL通过特殊地标记旧行来避免这种灾难性的数据丢失，这样无论它们与当前事务id处于什么位置，它们都是可见的。 Freezing冻结是对旧的活元组(即数据库行)进行标记的过程，这样它们就不会被变化的事件范围覆盖，否则它们就会在未来出现。这与vacuum相反，vacuum指的是释放那些已死的元组所占用的空间，这些元组对任何事务都不再可见。
一年前，我曾经发文介绍过PostgreSQL的Decoding工具wal2json。其目的在于将PG的WAL中的改变记录（主要指DML涉及的数据变更信息）转化为可读信息，提供给运维人员做后续数据的处理。文章中虽提及Debezium项目，但并没有介绍Debezium项目实践的内容。 Debezium是基于Apache Kafka 项目建立，并为 Kafka Connect 提供兼容性插件，用于管理数据库系统，将数据库日志中的事件记录转化为事件流，并将这些改变的事件流记录到Kafka中。当应用（数据库）出现不可期的异常中断时，作为数据的消费者扔可以借用kafka记录的改变事件流对数据进行准确和完整的数据处理。
为了提高数据访问的速度，一般数据库操作系统都会引入内存作为缓存，而为了方便管理和合并I/O，一般会开辟一个缓存池（buffer pool）。本文主要讲述PostgreSQL 如何进行缓存池管理。
并发控制是多个事务在并发运行时，数据库保证事务一致性（Consistency）和隔离性（Isolation）的一种机制。主流商用关系数据库使用的并发控制技术主要有三种：严格两阶段封锁（S2PL）、多版本并发控制（MVCC）和乐观并发控制（OCC）。
经历过小型机时代的运维人员都有一个感觉，好像是小型机上的CPU更经用一些，特别是IBM的小型机。哪怕是CPU使用率达到100%，系统好像还不感觉太慢。而在LINUX上就不同了，CPU使用率高了确实系统就立马变慢了，甚至不用达到100%，系统就慢的可以了。记得十多年前，一个客户为了图便宜，买了一批P5 的P595，系统刚上线，很快CPU使用率就100%了，虽然系统并没感觉慢，不过网管系统整天发告警也是受不了。于是我建议他们不再关注CPU使用率，而是关注r队列的长度，如果r队列的长度达到CPU核数的3倍，才开始报警，当r队列长度超过CPU核数的4倍的时候，系统才开始感觉有些慢。