Japin

最近在使用 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

在之前的文章中，我们讨论了系统如何规划查询以及如何收集统计信息以选择最佳执行计划。从这篇文章开始，后续的文章将终点关注计划的本质、它的组成以及如何执行。

在本文中，我将演示规划器如何计算执行成本。我还将讨论访问方法（Access Methods）以及它们如何影响这些成本，并使用顺序扫描方法作为说明。最后，我将谈谈 PostgreSQL 中的并行执行的工作原理以及何时使用它。

我将在本文后面使用几个看似复杂的数学公式。您无需记住任何一个公式也可以理解规划器是如何工作的；它们只是为了显示我的数据来源。