postgres 14 "create publication" 卡了几个小时
postgres 14 "create publication" stuck for hours
我使用 pg_upgrade --link 选项从 Postgres 10 升级到 Postgres 14。数据库总大小约为 10TB。 pg_upgrade 成功且快速并且喜欢建议的工具 -
Optimizer statistics are not transferred by pg_upgrade. Once you start the new server, consider running: /usr/pgsql-14/bin/vacuumdb --all --analyze-in-stages
我运行上面的命令但是进程卡住了。作为此（或不确定，不确定）的副作用，当我创建一个出版物时，提示永远不会回来，即使在几个小时后也没有创建该出版物。
postgres=# select * 来自 pg_stat_progress_vacuum;
c1
c2
pid
9520
datid
16402
datname
xyz
relid
22423
phase
vacuuming indexes
heap_blks_total
232816470
heap_blks_scanned
36766348
heap_blks_vacuumed
0
index_vacuum_count
0
max_dead_tuples
11184809
num_dead_tuples
11184521
这与昨天的输出相同。我可以做些什么来加快这个和“创建发布”命令的速度？
附带说明：Postgres 运行 所在的虚拟机非常强大（64GB RAM，16 核）。
谢谢！
编辑 1：pg_stat_activity 相同 pid 的输出，
c1
c2
pid
9520
backend_start
2021-12-06 15:13:23.479071-08
xact_start
2021-12-06 15:13:23.512581-08
query_start
2021-12-06 15:13:23.512581-08
state_change
2021-12-06 15:13:23.512581-08
wait_event_type
Timeout
wait_event
VacuumDelay
state
active
backend_xmin
3140627534
query
autovacuum: VACUUM xyz (to prevent wraparound)
backend_type
autovacuum worker
vacuumdb --all --analyze-in-stages 不会 运行 VACUUM，而是 ANALYZE，所以你必须查看 pg_stat_progress_analyze 看看它是怎么做的。
您看到的 VACUUM 过程 运行ning 与此无关。它是一个当前正在休眠但正在处理的反环绕真空。 让它结束；这个过程对你的数据库的健康很重要。 如果你想在那个 table 上进一步的 autovacuum 运行s 更快地完成，减少那个 table 的 autovacuum_vacuum_cost_delay ].
单纯升级应该不会导致反环绕真空到运行，所以它决定在升级后运行可能是时间上的巧合。另一方面，也许您的新数据库版本具有不同的配置设置，例如 autovacuum_freeze_max_age 的较低值，运行 这个新设置是触发它立即启动的原因。您是否将所有非默认配置设置从 v10 转移到 v14？
我同意 Laurenz 的观点，确实需要让它完成，但这并不意味着你需要让它现在完成。您可以终止 vacuuming 后端，以便您的 CREATE PUBLICATION 有机会 运行。 autovac 可能会立即重新启动，因此当您取消 vacuum 时，您应该让 CREATE PUBLICATION 已经尝试 运行。这样它将能够在 vacuum 再次启动并再次获取锁之前获取锁。但请确保您不会养成每次给您带来不便时取消吸尘器的习惯。
还有，你应该把maintenance_work_mem提高很多。看起来它当前设置为 64MB，这对于您描述的服务器来说是相当低的。如果您将其设置为 1GB，那么它应该能够仅通过一次索引而不是您目前正在执行的七次来清理整个 table。我会在取消 vacuum 之前更改 conf 文件中的此设置并 SIGHUP 服务器，这样启动的新 vacuum 应该具有新设置。
最后，我不知道为什么要清理索引。我认为 v14 对其进行了更改，以便紧急吸尘器不必费心这样做，而只是冻结堆中的元组并为以后留下索引。我想我需要多研究一下 v14 才能弄清楚它在这里到底做了什么。
我使用 pg_upgrade --link 选项从 Postgres 10 升级到 Postgres 14。数据库总大小约为 10TB。 pg_upgrade 成功且快速并且喜欢建议的工具 -
Optimizer statistics are not transferred by pg_upgrade. Once you start the new server, consider running: /usr/pgsql-14/bin/vacuumdb --all --analyze-in-stages
我运行上面的命令但是进程卡住了。作为此（或不确定，不确定）的副作用，当我创建一个出版物时，提示永远不会回来，即使在几个小时后也没有创建该出版物。
postgres=# select * 来自 pg_stat_progress_vacuum;
| c1 | c2 |
|---|---|
| pid | 9520 |
| datid | 16402 |
| datname | xyz |
| relid | 22423 |
| phase | vacuuming indexes |
| heap_blks_total | 232816470 |
| heap_blks_scanned | 36766348 |
| heap_blks_vacuumed | 0 |
| index_vacuum_count | 0 |
| max_dead_tuples | 11184809 |
| num_dead_tuples | 11184521 |
这与昨天的输出相同。我可以做些什么来加快这个和“创建发布”命令的速度？ 附带说明：Postgres 运行 所在的虚拟机非常强大（64GB RAM，16 核）。 谢谢！
编辑 1：pg_stat_activity 相同 pid 的输出，
| c1 | c2 |
|---|---|
| pid | 9520 |
| backend_start | 2021-12-06 15:13:23.479071-08 |
| xact_start | 2021-12-06 15:13:23.512581-08 |
| query_start | 2021-12-06 15:13:23.512581-08 |
| state_change | 2021-12-06 15:13:23.512581-08 |
| wait_event_type | Timeout |
| wait_event | VacuumDelay |
| state | active |
| backend_xmin | 3140627534 |
| query | autovacuum: VACUUM xyz (to prevent wraparound) |
| backend_type | autovacuum worker |
vacuumdb --all --analyze-in-stages 不会 运行 VACUUM，而是 ANALYZE，所以你必须查看 pg_stat_progress_analyze 看看它是怎么做的。
您看到的 VACUUM 过程 运行ning 与此无关。它是一个当前正在休眠但正在处理的反环绕真空。 让它结束；这个过程对你的数据库的健康很重要。 如果你想在那个 table 上进一步的 autovacuum 运行s 更快地完成，减少那个 table 的 autovacuum_vacuum_cost_delay ].
单纯升级应该不会导致反环绕真空到运行，所以它决定在升级后运行可能是时间上的巧合。另一方面，也许您的新数据库版本具有不同的配置设置，例如 autovacuum_freeze_max_age 的较低值，运行 这个新设置是触发它立即启动的原因。您是否将所有非默认配置设置从 v10 转移到 v14？
我同意 Laurenz 的观点，确实需要让它完成，但这并不意味着你需要让它现在完成。您可以终止 vacuuming 后端，以便您的 CREATE PUBLICATION 有机会 运行。 autovac 可能会立即重新启动，因此当您取消 vacuum 时，您应该让 CREATE PUBLICATION 已经尝试 运行。这样它将能够在 vacuum 再次启动并再次获取锁之前获取锁。但请确保您不会养成每次给您带来不便时取消吸尘器的习惯。
还有，你应该把maintenance_work_mem提高很多。看起来它当前设置为 64MB，这对于您描述的服务器来说是相当低的。如果您将其设置为 1GB，那么它应该能够仅通过一次索引而不是您目前正在执行的七次来清理整个 table。我会在取消 vacuum 之前更改 conf 文件中的此设置并 SIGHUP 服务器，这样启动的新 vacuum 应该具有新设置。
最后，我不知道为什么要清理索引。我认为 v14 对其进行了更改，以便紧急吸尘器不必费心这样做，而只是冻结堆中的元组并为以后留下索引。我想我需要多研究一下 v14 才能弄清楚它在这里到底做了什么。