PgSQL · 内核开发 · 如何管理你的 PostgreSQL 插件

一.背景 我们都知道 PostgreSQL 提供了丰富数据库内核编程的接口，允许开发者以插件的形式把功能融入数据库内核。 PostgreSQL 提供了一个插件管理模块，用于管理用户创建的插件。 本文给大家介绍 PostgreSQL 插件管理模块，帮助大家管理自己的插件。 二.PostgreSQL的插件内容 通常一个 PostgreSQL 内核插件包括下面的部分

我们都知道 PostgreSQL 提供了丰富数据库内核编程的接口，允许开发者以插件的形式把功能融入数据库内核。

PostgreSQL 提供了一个插件管理模块，用于管理用户创建的插件。

本文给大家介绍 PostgreSQL 插件管理模块，帮助大家管理自己的插件。

二.PostgreSQL的插件内容

通常一个 PostgreSQL 内核插件包括下面的部分

2. 描述插件信息的的控制文件，即 control 文件。 3. 一组文件用于创建、更新和删除插件，这是一组按照版本命名的 SQL 文本文件。

如果缺少了上述部分，或版本号不正确，插件的管理功能会异常。

三.插件的管理

我们使用 create extension， drop extension alter extension 管理指定的插件。

1.插件的创建

例如 postgres_fdw 的创建

create extension postgres_fdw;

drop extension postgres_fdw;

我们可以选择把插件创建到指定的模式中。

2.插件的管理视图

这是最简单的部分，创建插件后，我们可以通过插件管理视图看到一些细节信息

select * from pg_extension ;

 extname | extowner | extnamespace | extrelocatable | extversion | extconfig | extcondition 

--------------+----------+--------------+----------------+------------+-----------+-------------- 

 postgres_fdw | 10 | 2200 | t | 1.0 | | 

可以看到，postgres_fdw 的 owner, 存在的 schema 和插件的小版本。

3.插件的删除

插件的内容可以是任何的数据库对象，例如：函数、操作符等等。

这些对象可能被其他的对象引用，例如我们在 postgres_fdw 创建了基于 postgres_fdw 的外部表。

当我们要删除 postgres_fdw 时，需要加上 cascade 子句，把相关对象一并删除。

drop extension postgres_fdw cascade;

这么做带来的问题是，所有依赖这个插件的对象都会被删除。再次使用需要重建。

4.插件的更新

有时候，我们需要做插件的 BUGFIX ，或定制一些功能。这就用到了插件更新功能。

修改控制文件 .control, 增加一个小版本，如果当前版本是 1.1，则文件中版本号修改成 1.2

该 SQL 文件只包含 1.2 版本中新创建的对象。用户的升级操作会调用该 SQL 文件，从而避免了完全重新创建。

postgres=# select * from pg_extension ;

 extname | extowner | extnamespace | extrelocatable | extversion | extconfig | extcondition 

--------------+----------+--------------+----------------+------------+-----------+--------------

postgres_fdw | 10 | 2200 | t | 1.2 | | 

(2 rows)

使用 PostgreSQL 的插件管理功能，用户很容开发和维护需要的插件。

有几点需要特别提醒，这是在开发和管理插件时，经常碰到的问题，需要多加注意

插件是通过动态库形式引入到内核中。和内核在同一个进程中运行，且没有内存保护，影响内核的稳定性。开发中需要特别注意内存的使用。不要造成内存泄露或越界写。建议使用 PostgreSQL 的内存管理机制，插件中也能使用。 内核中被标记成 PGDLLIMPORT 的全局变量都能在插件中直接使用，这些通常是一些 GUC 参数。 内核中非 static 的函数也能在插件中使用，只需要先 extern 它们。 我们可以实现 _PG_init 用于实现一些初始化工作，该函数在连接建立后只会被执行一次。 我们可以在 _PG_init 中使用函数 DefineCustom*Variable 定义对应插件相关的 GUC 参数，他们可以用于开启和关闭该插件的一些功能。 插件的参数需要以插件名开头且加上点，例如 oss_fdw.enable_parallel_read。 PostgreSQL 插件的创建 PostgreSQL 插件的删除 PostgreSQL 插件的修改/升级
PgSQL · 特性分析 · 浅析PostgreSQL 中的JIT title: PgSQL · 特性分析 · 浅析PostgreSQL 中的JIT author: 卓刀 ## 背景 估计很多同学看过之前的月报[PgSQL · 特性分析· JIT 在数据仓库中的应用价值](http://mysql.taobao.org/monthly/2016/11/10/)，对JIT（just in time）和LLVM（Low Level Vir
PgSQL · 应用案例 · 阿里云 RDS PostgreSQL 高并发特性 vs 社区版本 进程模型数据库，需要为每个会话指派独立的进程与之服务，在连接数非常多，且大都是活跃连接时，进程调度浪费或引入的开销甚至远远大于实际任务需要的开销（例如上下文切换，MEMCPY等），性能下降会较为严重。
PgSQL · 案例分享 · PostgreSQL 性能诊断指南 数据库的性能优化是一个非常经典的话题，数据库的优化手段以及优化的角度也各不相同。 例如，可以从OS内核、网络、块设备、编译器、文件系统、SQL、数据库参数、业务逻辑、源码等各个方面去进行优化。 但是如果在优化前了解瓶颈在什么地方，可以向打鼹鼠一样，先打大的，起到事半功倍的效果。 本文将针对Linux平台下的PostgreSQL服务，讲解如何诊断PostgreSQL 数据库服务的瓶颈，了
PgSQL · 特性分析 · PostgreSQL 9.6 如何把你的机器掏空 PostgreSQL 在向和纵向的扩展能力在开源数据库中一直处于非常领先的地位，例如今年推出的9.6，内置了sharding的功能，同时在scale-up的能力也有非常明显的提升，特别是在多核与高并发处理这块。 社区有同学在128核的机器上测试tpc-b的select only模式可以达到几百万的qps，机器的CPU资源被吃光光。 天下大势，分久必合，合久必分。谈了这么多年的shardi
PgSQL · 代码浅析 · PostgreSQL 可靠性分析 PostgreSQL 可靠性与大多数关系数据库一样，都是通过REDO来保障的。 群里有位童鞋问了一个问题，为什么PostgreSQL的REDO块大小默认是8K的，不是512字节。 这位童鞋提问的理由是，大多数的块设备扇区大小是512字节的，512字节可以保证原子写，而如果REDO的块大于512字节，可能会出现partial write。 那么PostgreSQL的redo(wal) 块
PgSQL · 实战经验 · 旋转门压缩算法在PostgreSQL中的实现 在物联网、监控、传感器、金融等应用领域，数据在时间维度上流式的产生，而且数据量非常庞大。 例如我们经常看到的性能监控视图，就是很多点在时间维度上描绘的曲线。 又比如金融行业的走势数据等等。 我们想象一下，如果每个传感器或指标每100毫秒产生1个点，一天就是864000个点。 而传感器或指标是非常多的，例如有100万个传感器或指标，一天的量就接近一亿的量。 假设我们要描绘一个时间
MySQL · 社区贡献 · AliSQL那些事儿 一直以来我们都在不断对我们的阿里云MySQL分支做极致的性能优化及功能扩展。我们从社区的分支，如上游版本及Percona Server上学习新的改进和功能，并引入到我们的分支中。同时我们也将我们的一些改进思路反馈到上游，让整个社区也能享受到我们的成果。 本文主要介绍下AliSQL贡献给上游MySQL5.7版本的一些跟性能相关的优化。注意这里只摘取了几个比较有意思的优化，在即将开源的AliSQL中
MySQL · 特性分析 · MyRocks简介 RocksDB是facebook基于LevelDB实现的，目前为facebook内部大量业务提供服务。经过facebook大量工作，将RocksDB作为MySQL的一个存储引擎移植到MySQL，称之为MyRocks。 经过两年的发展，MyRocks已经比较成熟（RC阶段），现已进入了facebook MySQL的主分支了。MyRocks是开源的,参见git 。 下面对MyRocks做一个简单介绍，
db匠 rds内核团队秘密研发的全自动卖萌机. 追加特效: 发数据库内核月报. 月报传送: http://mysql.taobao.org/monthly/