03 PostgreSQL 创建插件实现原理

PostgreSQL 内核中使用 CREATE EXTENSION 创建插件时，首先，会解析插件的控制文件，取出需要执行的 sql 脚本版本号，同时根据控制文件的插件元数据信息创建 extension_oid 一起存入到系统表 pg_extension 中。然后，通过解析并执行相对应的 sql 脚本文件，完成插件所需的视图和函数等内容的创建。如果使用的是源码文件创建的函数，在调用 CREATE FUNCTION 创建函数时，会通过加载插件动态库 so 文件来调用具体函数。

下面，通过控制文件处理过程，SQL 脚本文件路径查找过程和动态库函数调用过程三个部分详细介绍创建插件实现原理。

3.1 控制文件处理过程

PostgreSQL 中使用 CREATE EXTENSION 创建插件时控制文件的处理过程如下图所示：

ProcessUtilitySlow 函数解析到的 SQL 命令是  CREATE EXTENSION 时，就会调用 CreateExtension 函数执行具体插件创建过程；

该过程中使用 read_extension_control_file 和 parse_extension_control_file 两个函数读取并解析插件控制文件中的信息，通常包括扩展的名称、版本、依赖关系等；

然后，调用 InsertExtensionTuple 函数将控制文件中包含的插件元数据信息插入到系统表 pg_extension 中；

接着，调用 execute_extension_script 和 execute_sql_string 函数，根据获取到的 SQL 脚本路径，读取并执行 SQL 脚本；执行过程与 PostgreSQL 中一般的查询处理过程一致：

• 首先，调用 pg_parse_query 将 sql 转换成 parsetree_list；
• 然后，执行 pg_analyze_and_rewrite 对 SQL 脚本进行解析和重写；
• 接着，调用 pg_plan_queries() 函数生成查询计划；
• 最后，调用 ExecutorRun 对每一个 parse tree 进行执行。

上述过程中各函数作用的具体说明如下：

• ProcessUtilitySlow()：处理 SQL 命令的函数，它会对传入的SQL命令进行解析和执行；如果 SQL 命令是创建插件的命令，就会调用CreateExtension() 函数执行相关逻辑。
• CreateExtension()：解析 SQL 命令中的插件信息，然后调用 CreateExtensionInternal() 函数进行实际的创建操作。
• CreateExtensionInternal()：读取插件控制文件中的信息，然后插入插件元组到 pg_extension 表中，最后执行插件脚本。
• read_extension_control_file()：读取扩展控制文件中的信息，包括扩展的名称、版本、依赖关系等。
• parse_extension_control_file()：解析扩展控制文件中的信息，取出调用具体版本，文件名等信息。
• InsertExtensionTuple()：这个函数会将插件元组插入到 pg_extension 表，把控制文件的信息保存到 Tuple 中。
• execute_extension_script()：调用 execute_sql_string() 函数执行扩展脚本
• execute_sql_string(): 解析 sql 脚本文件并执行

3.2 SQL 脚本文件路径查找过程

PostgreSQL 中使用 CREATE EXTENSION 创建插件时处理完控制文件之后，会执行插件的 SQL 脚本，而这些脚本文件则需要根据控制文件中提供的插件版本等信息查找文件路径，该过程如下图所示：

在 CreateExtensionInternal 函数中处理插件控制文件的后，调用 get_ext_ver_list 和 get_ext_ver_info 函数获取插件的所有版本列表和具体版本信息；

然后，调用 find_install_path 和 find_update_path 函数查找某个需要执行脚本所在的路径，并通过 get_extension_script_filename 函数根据 SQL 脚本文件命名规则获取 sql 具体文件名称。

上述过程中各函数作用的具体说明如下：

• get_ext_ver_list() ：获取指定插件的所有版本列表
• get_ext_ver_info() ：获取指定插件的某个版本的信息；根据目标节点选择最短路径以及相对应的起始节点
• find_install_path() ：根据插件名称和版本信息，在 PostgreSQL 的插件目录中查找对应的插件目录
• find_update_path() ：当前插件版本和要升级到的版本，查找升级脚本所在的目录，使用最短路径算法 Dijkstra 实现

3.3 动态库函数创建过程

如果 PostgreSQL 插件中使用的是源码文件创建具体功能函数，那么在执行 SQL 脚本中使用 CREATE FUNCTION 创建函数时，会通过如下图所示过程加载插件动态库 so 文件来调用具体函数：

ProcessUtilitySlow 解析得到的 SQL 语句是创建函数的命令时，就会调用 CreateFunction 函数来执行具体过程，该函数中调 ProcedureCreate 创建一个新的函数，包括函数的名称、参数、返回值类型、语言、代码等内容；

ProcedureCreate 函数中使用 OidFunctionCall1 或 OidFunctionCall1Coll 调用指定函数的执行代码，该函数中使用 fmgr 提供的接口 fmgr_info 获取函数信息和函数指针；

然后，在 load_external_function 函数中调用 internal_load_library 函数根据函数指针在插件动态库中获取指定的函数实现逻辑

上述过程中各函数作用的具体说明如下：

• ProcessUtilitySlow()：处理 SQL 命令的函数，它会对传入的 SQL 命令进行解析和执行；如果 SQL 命令是创建函数的命令，就会调用 CreateFunction() 函数继续处理相应逻辑。
• CreateFunction()：解析 SQL 命令中的函数信息，并调用 ProcedureCreate() 函数创建函数。
• ProcedureCreate()：创建一个新的函数，包括函数的名称、参数、返回值类型、语言、代码等。通过调用 fmgr_info() 函数获取函数的信息，并调用 OidFunctionCall1() 或 OidFunctionCall1Coll() 函数执行函数代码。
• OidFunctionCall1() 和 OidFunctionCall1Coll()：这两个函数用于调用指定函数的执行代码，调用 fmgr 提供的接口。
• fmgr_info()、fmgr_info_cxt_security() 和 fmgr_info_C_lang()：这些函数都是获取函数信息的函数；其中，fmgr_info() 函数获取函数的信息，包括输入输出参数、返回值类型、函数实现等；fmgr_info_cxt_security() 函数获取函数的安全上下文；fmgr_info_C_lang() 函数获取函数的实现语言和实现方式。
• load_external_function()：加载指定的外部函数库，并返回函数指针。
• internal_load_library()、dlopen()、dlsym() 和 LoadLibrary()：这些函数都是加载外部函数库的函数；其中，internal_load_library() 函数是 PostgreSQL 自己实现的加载函数库的函数，先判断是否 load，如果没有则通过调用 dlopen() 函数进行 load，然后使用 dlsym() 查找相关函数；
• LoadLibrary() 函数是 Windows 系统中的加载函数库的函数。

3.4 动态库函数调用过程

使用 CREATE EXTENSION 完成插件创建之后，就可以调用插件提供的函数了

PostgreSQL 中所有的函数调用都会调用 OidInputFunctionCall 函数进行处理，该函数实现如下，首先使用 fmgr_info 函数从插件动态库获取函数指针，然后调用 InputFunctionCall 函数调用指定函数。

Datum
OidInputFunctionCall(Oid functionId, char *str, Oid typioparam, int32 typmod)
{
	FmgrInfo	flinfo;

	fmgr_info(functionId, &flinfo);
	return InputFunctionCall(&flinfo, str, typioparam, typmod);
}

fmgr_info 中获取函数指针的过程和以及其他相关信息，对于系统函数则从 Tuple 中获取；对于动态库中函数，则调用 fmgr_info_C_lang 来获取函数指针

fmgr_info_C_lang 的实现如下所示，和动态库创建过程中的动态库加载过程一样，都是通过调用 load_external_function 函数加载动态库并获取函数指针

static void
fmgr_info_C_lang(Oid functionId, FmgrInfo *finfo, HeapTuple procedureTuple)
{
	CFuncHashTabEntry *hashentry;
	PGFunction	user_fn;
	const Pg_finfo_record *inforec;
	bool		isnull;

	/*
	 * See if we have the function address cached already
	 */
	hashentry = lookup_C_func(procedureTuple);
	if (hashentry)
	{
		user_fn = hashentry->user_fn;
		inforec = hashentry->inforec;
	}
	else
	{
		Datum		prosrcattr,
					probinattr;
		char	   *prosrcstring,
				   *probinstring;
		void	   *libraryhandle;

		prosrcattr = SysCacheGetAttr(PROCOID, procedureTuple,
									 Anum_pg_proc_prosrc, &isnull);
		if (isnull)
			elog(ERROR, "null prosrc for C function %u", functionId);
		prosrcstring = TextDatumGetCString(prosrcattr);

		probinattr = SysCacheGetAttr(PROCOID, procedureTuple,
									 Anum_pg_proc_probin, &isnull);
		if (isnull)
			elog(ERROR, "null probin for C function %u", functionId);
		probinstring = TextDatumGetCString(probinattr);

		/* Look up the function itself */
		user_fn = load_external_function(probinstring, prosrcstring, true,
										 &libraryhandle);

		/* Get the function information record (real or default) */
		inforec = fetch_finfo_record(libraryhandle, prosrcstring);

		/* Cache the addresses for later calls */
		record_C_func(procedureTuple, user_fn, inforec);

		pfree(prosrcstring);
		pfree(probinstring);
	}

	switch (inforec->api_version)
	{
		case 1:
			/* New style: call directly */
			finfo->fn_addr = user_fn;
			break;
		default:
			/* Shouldn't get here if fetch_finfo_record did its job */
			elog(ERROR, "unrecognized function API version: %d",
				 inforec->api_version);
			break;
	}
}

动态库加载过程中使用的 dlopen， dlsym 函数是 dlfcn 库提供一组函数接口：dlopen 可以在运行时动态加载共享库 、 dlsym 可以查找动态链接库中的符号即函数或变量、而 dlclose 用于关闭已加载的动态库。

这几个函数在 PostgreSQL 后台进程运行过程中的作用如下图所示，使用 dlopen 在运行时将插件动态库加载到后台进程的内存映射区域，然后使用 dlsym 在动态库中查找函数并返回函数指针，这样进程在调用该函数时就根据函数指针执行动态库中的函数实现。

如果文章对你有帮助，欢迎一键三连 👍 ⭐️ 💬 。如果还能够点击关注，那真的是对我最大的鼓励 🔥 🔥 🔥 。