Japin

您好！我正在开始另一个关于 PostgreSQL 内部的文章系列。这一篇将侧重于查询计划和执行机制。本系列将涵盖：

1. 查询执行阶段（本文）
2. 统计信息
3. 顺序扫描
4. 索引扫描
5. 嵌套循环连接
6. Hash 连接
7. 归并连接

本文借鉴了我们的 QPT 查询优化课程（即将推出英文版），但主要关注查询执行的内部机制，而将优化方面放在一边。另请注意，本系列文章是针对 PostgreSQL 14 编写的。

最近在邮件列表中看到一个关于聚集列的数据类型修改导致的异常问题 BUG #17409。本文简要记录一下分析过程以及解决方案。目前该问题已经被修复，在 14.1 和 14.2 版本中应该可以重现。

commit 641f3dffcdf1c7378cfb94c98b6642793181d6db
Author: Tom Lane <tgl@sss.pgh.pa.us>
Date:   Fri Mar 11 13:47:26 2022 -0500

    Restore the previous semantics of get_constraint_index().

    Commit 8b069ef5d changed this function to look at pg_constraint.conindid
    rather than searching pg_depend.  That was a good performance improvement,
    but it failed to preserve the exact semantics.  The old code would only
    return an index that was "owned by" (internally dependent on) the
    specified constraint, whereas the new code will also return indexes that
    are just referenced by foreign key constraints.  This confuses ALTER
    TABLE, which was implicitly expecting the previous semantics, into
    failing with errors like
        ERROR:  relation 146621 has multiple clustered indexes
    or
        ERROR:  "pk_attbl" is not an index for table "atref"

    We can fix this without reverting the performance improvement by adding
    a contype check in get_constraint_index().  Another way could be to
    make ALTER TABLE check it, but I'm worried that extension code could
    also have subtle dependencies on the old semantics.

    Tom Lane and Japin Li, per bug #17409 from Holly Roberts.
    Back-patch to v14 where the error crept in.

    Discussion: https://postgr.es/m/17409-52871dda8b5741cb@postgresql.org

申威上面的编译器问题看来还不少，上一篇文章说到了浮点型优化的问题，今天又遇到指令操作数越界的问题（虽然是个警告，但不排除可能存在其它隐含的问题）。

今天灿灿（微信公众号：PostgreSQL 学徒）发来一个问题，说是日志中 buffer usage 出现了负数，如下所示。

最近在做申威平台的兼容时发现一个关于编译器优化的 BUG。第一次遇到编译器优化的问题，因此在这里对其进行简要的记录。

PostgreSQL 提供了自定义参数的功能，您可以使用 SET 或 set_config() 函数来定义参数，本文介绍一下在 PG14（14.1 和 14.2）中引入的关于自定义参数标识符的的问题 BUG #17415。

最近在分析 bug 的时候接触到了 git bisect 这个命令，虽然之前也知道这个命令，但是由于平时用的不多所以没有深入的研究，对它的使用方法也不是很熟悉。其实这个命令使用起来还是非常简单的，本文结合实际情况简要介绍一下 git bisect 的使用方法。

最近在邮件列表中发现 CREATE OR REPLACE VIEW 存在一个 bug，无法更新输出列的 collation。如下所示：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

postgres=# CREATE TABLE tbl (info text);
CREATE TABLE
postgres=# CREATE VIEW my_tbl_view AS SELECT info FROM tbl;
CREATE VIEW

postgres=# \d+ my_tbl_view
                        View "public.my_tbl_view"
 Column | Type | Collation | Nullable | Default | Storage  | Description
--------+------+-----------+----------+---------+----------+-------------
 info   | text |           |          |         | extended |
View definition:
 SELECT tbl.info
   FROM tbl;

postgres=# CREATE OR REPLACE VIEW my_tbl_view AS SELECT info COLLATE "en_US.utf8" FROM tbl;
CREATE VIEW
postgres=# \d+ my_tbl_view
                        View "public.my_tbl_view"
 Column | Type | Collation | Nullable | Default | Storage  | Description
--------+------+-----------+----------+---------+----------+-------------
 info   | text |           |          |         | extended |
View definition:
 SELECT tbl.info COLLATE "en_US.utf8" AS info
   FROM tbl;

可以看到在 Collation 列中没有发生改变，而且也没任何提示，只是默默的丢弃了 COLLATE "en_US.utf8"，但是在视图的定义中又更新了 Collation，这多少让人有点疑惑。

今天遇到关于私钥格式的问题，需要通过远程连接访问远端的服务器，该服务器是客户给的，然后通过 ssh 的方式访问，然而客户给的私钥是如下形式的：

1
2
3

-----BEGIN OPENSSH PRIVATE KEY-----
b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAA...
-----END OPENSSH PRIVATE KEY-----

通过 ssh 连接时报无效的格式，Load key "~/.ssh/openssh_id_rsa": invalid format。本文简要记录一下解决方法。

最近看到一个问题，说是在 ExecIndexBuildScanKeys() 函数中的 isorderby 参数在有 ORDER BY 字句时，IndexScan 中的 indexorderby 也为空。例如下面两个查询：

1
2

SELECT col FROM table_name ORDER BY index_key op const LIMIT 5;
SELECT col FROM table_name WHERE index_key op const;

这两个查询在执行 ExecIndexBuildScanKeys() 时 IndexScan 结构中的 indexorderby 均为空。然而，IndexScan->indexorderby 的注释为 list of index ORDER BY exprs，即 ORDER BY 语句后面的索引表达式，第一个 SQL 语句明显有 ORDER BY 字句，那么为什么此时的 indexorderby 为空呢？