postgres 14“创建出版物”停留了几个小时答案

【问题标题】：postgres 14 "create publication" stuck for hourspostgres 14“创建出版物”停留了几个小时
【发布时间】：2022-01-12 18:09:51
【问题描述】：

我使用 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 * from 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 的 VM 非常强大（64GB RAM，16 核）。谢谢！

edit 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

【问题讨论】：

标签： postgresql logical-replication pg-upgrade

【解决方案1】：

仅仅进行升级不应该导致反环绕真空运行，因此它决定在升级后立即运行可能是时间巧合。另一方面，也许您的新数据库版本有不同的配置设置，例如autovacuum_freeze_max_age 的值较低，使用这个新设置运行是触发它立即启动的原因。您是否将所有非默认配置设置从 v10 转移到 v14？

我同意 Laurenz 的观点，他确实需要让这件事完成，但这并不意味着你需要让它现在就完成。您可以终止清理后端，以便您的 CREATE PUBLICATION 有机会运行。 autovac 可能会立即重新启动，因此当您取消真空时，您应该已经尝试运行 CREATE PUBLICATION。这样，它就能够在真空再次启动并再次获取锁之前获取锁。但请确保您不会养成每次给您带来不便时取消吸尘器的习惯。

另外，你应该将maintenance_work_mem 增加很多。看起来它当前设置为 64MB，这对于您描述的服务器来说是相当低的。如果您将其设置为 1GB，那么它应该能够只通过索引一次而不是您目前正在准备的七次来清理整个表。在取消真空之前，我会在 conf 文件中更改此设置并 SIGHUP 服务器，这样启动的新真空应该具有新设置。

最后，我不知道为什么要清理索引。我认为 v14 改变了它，以便紧急清理不会费心去做，而是冻结堆中的元组并将索引留给以后使用。我想我需要多研究一下 v14 才能弄清楚它在这里的真正作用。

【讨论】：

autovacuum_freeze_max_age 值是 V10 和 V14 中的默认值。不知道是否触发了反环绕真空，因为我们从我们的实时实例和两个 VM（一个运行 v10 和另一个 v14）上创建了 2 个 VM 副本，我看到相同的真空过程正在运行。感谢您澄清我现在不需要等待真空过程完成（因为它仍在运行）！
当我应用配置更改并终止了它立即启动的早期进程时，您对反环绕真空的看法是正确的，但是我再次终止了该进程以“创建发布”并且很快就成功了。现在反环绕真空过程又出现了，这次我会让它运行。现在为逻辑复制计时会很有趣。

【解决方案2】：

vacuumdb --all --analyze-in-stages 不会运行 VACUUM，而是运行 ANALYZE，因此您必须查看 pg_stat_progress_analyze 以了解它的运行情况。

您看到运行的VACUUM 进程与此无关。这是一个反环绕式真空吸尘器，目前正在休眠，但正在处理中。 让它完成；此过程对您的数据库的运行状况很重要。如果您希望在该表上进一步运行 autovacuum 以更快地完成，请减少该表的 autovacuum_vacuum_cost_delay。

【讨论】：

pg_stat_progress_analyze 输出为空，所以分阶段分析可能已经完成？是的，每次pg_stat_progress_vacuum 的输出都完全相同。我还没有调整任何 autovacuum 参数。我可以看看。谢谢。在pg_stat_activity 中，我看到了同一个 pid 的一个有趣的行，并用输出编辑了我的问题。
感谢您编辑您的回答 Laurenz。如何获得该过程的进展？ pg_stat_activity 的 state_change 字段根本没有更新。该过程正在减慢整个数据库的速度。我无法设置逻辑/流复制 - 这是预期的吗？
是的，这是意料之中的。它目前正在扫描和清理索引。让它完成。