Japin

PostgreSQL 允许数据库会话同步它们的快照。快照确定哪些数据对使用快照的事务可见。当两个或多个会话需要查看数据库中的相同内容时，需要同步快照。如果两个会话只是独立地开始它们的事务，在两个 START TRANSACTION 命令的执行之间总是有可能提交第三个事务，这样一个会话可以看到该事务的效果，而另一个则看不到。

为了解决这个问题，PostgreSQL 允许事务导出它正在使用的快照。只要导出快照的事务保持打开状态，其他事务就可以导入这个快照，从而保证它们看到的数据库视图与第一个事务看到的完全相同。

快照可以通过 pg_export_snapshot() 函数导出，并通过 SET TRANSACTION 命令导入。本文我将从源码角度分析一下快照导出和导入的流程。

最近在使用 IRC 的时候发现 Emacs 的 ERC 不能登录 IRC 了，提示如下错误信息：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

Opening connection..                                                    [13:47]
-zinc.libera.chat- *** Checking Ident
-zinc.libera.chat- *** Looking up your hostname...
-zinc.libera.chat- *** No Ident response
-zinc.libera.chat- *** Couldn't look up your hostname
-zinc.libera.chat- *** Notice -- SASL authentication to a NickServ account
                 with a verified email address is required to connect from
                 your current network. Please see
                 https://libera.chat/guides/sasl for configuration assistance.
==> ERROR from irc.libera.chat: Closing Link: 117.139.163.129 (SASL
    authentication to a NickServ account with a verified email address is
    required to connect from your current network. Please see
    https://libera.chat/guides/sasl for configuration assistance.)


Connection failed!  Not re-establishing connection.


*** ERC terminated: connection broken by remote peer

本文简要记录一下 PostgreSQL 中有关子事务相关的处理，PostgreSQL 中子事务（pg_subtrans）的管理与事务管理（pg_xact）类似，它存储了每个事务的父事务 ID。它是实现嵌套事务的基本组成部分。主事务（即顶层事务）的父事务 ID 为 InvalidTransactionId，每个子事务都有其直接的父事务 ID。因此，我们可以通过子事务遍历很容易找到父事务 ID，反之则不然。

pg_subtrans 只记录当前已打开的事务，因此无需为崩溃或重启持久化数据。在重启时，PostgreSQL 会将当前获取的页面清零。

今天朋友在群里发了一个关于文本搜索字典导致崩溃的问题，如下所示：

1
2
3
4
5
6
7
8

CREATE TEXT SEARCH TEMPLATE public.my_ts_template(
  init = varchar_support,
  lexize = dispell_lexize
);

CREATE TEXT SEARCH DICTIONARY public.my_ts_dict(
  template = public.my_ts_template
);

在执行第二条语句时将出现如下错误信息：

1
2
3
4
5

server closed the connection unexpectedly
        This probably means the server terminated abnormally
        before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.
The connection to the server was lost. Attempting reset: Failed.

从上面的信息可以得知后端进程奔溃了（这个问题就目前的状况来看是不会修正的）。

在上一篇文章中介绍了如何修改用户或数据库级别的参数，以及它们的存储位置（pg_db_role_setting 系统表），本文简要说明一下关于这里的参数配置不当，从而导致无法连接数据库的问题。

PostgreSQL 支持不同级别的参数配置，最简单的是全局配置，此外还有针对用户级别和数据库级别的配置，本文就来看看 PostgreSQL 中用户级别和数据库级别的配置的实现。

我们可以实现下面的 SQL 命令来修改用户级别的配置：

1
2
3
4

ALTER ROLE { role_specification | ALL } [ IN DATABASE database_name ] SET configuration_parameter { TO | = } { value | DEFAULT }
ALTER ROLE { role_specification | ALL } [ IN DATABASE database_name ] SET configuration_parameter FROM CURRENT
ALTER ROLE { role_specification | ALL } [ IN DATABASE database_name ] RESET configuration_parameter
ALTER ROLE { role_specification | ALL } [ IN DATABASE database_name ] RESET ALL

从上面的语法可以看出 PostgreSQL 配置的灵活性，您可以针对某个用户进行配置，也可以针对某个用户连接某个数据库进行配置。

数据库级别的配置相对于用户级别来说就要简单一些了，如下所示：

1
2
3
4

ALTER DATABASE name SET configuration_parameter { TO | = } { value | DEFAULT }
ALTER DATABASE name SET configuration_parameter FROM CURRENT
ALTER DATABASE name RESET configuration_parameter
ALTER DATABASE name RESET ALL

PostgreSQL 数据库大部分操作都依赖于系统表，因此为了加速访问，PostgreSQL 针对系统表提供了两种缓存：RelCache 和 SysCache。RelCache 和 SysCache 都是进程本地的，每个 backend 进程启动的时候都将创建自己的 RelCache 和 SysCache。本文将简要介绍一下这两类缓存。

• RelCache 用于缓存表的 RelationData 结构（关系描述符 - reldesc），该结构由系统表中的元组构成。
• SysCache 用于缓存系统表的元组信息。

在使用 pg_backtrace 插件时，必须执行 SELECT pg_backtrace_init();，不执行该函数插件就不生效，官方文档也特别说明了，而实际上该函数是一个空函数，为什么必须要执行该函数才生效呢？

这是一个朋友问我关于 pg_backtrace 的问题，这主要涉及到 PostgreSQL 中动态库的加载过程。本文在分析问题的基础之上，简要梳理一下 PostgreSQL 中动态库的加载过程。

今天在邮件列表中发现一个关于 psql 内存泄露的问题，经过测试，确实存在内存泄露。同时，我在查看周围的代码时，还发现其它地方也存在类似的内存泄漏。本文简要记录一下该问题。

PostgreSQL 的 repeat() 函数用于重复生成给定的字符串。例如：

1

repeat('abc', 3) -> 'abcabcabc'

最近在使用这个方法来生成 1GB 的数据时，遇到了一点问题。如下所示：

1
2

postgres=# CREATE TABLE myrepeat AS SELECT repeat('a', 1024 * 1024 * 1024);
ERROR:  invalid memory alloc request size 1073741828