问题标签 [autovacuum]

Postgres v11.9

Postgres 日志中有很多这样的错误：

手动真空也因此错误而失败。

我能做些什么来解决这个错误？

CentOS 7.9、postgres 9.6.20 我们在我们的 postgres 数据库中发现了我们认为是损坏的索引。这是在生产中，完全把它拉下来不是我们能做的。我们正在努力重新创建索引，但 autovacuum 似乎也试图处理索引。向 autovac pid 发送终止命令将被忽略。问题是我们如何禁用 autovacuum 足够长的时间来执行索引重新创建？
为了加剧这个问题，我们现在似乎已经达到了交易环绕限制，虽然距离实际限制还有数英里，但它不是一个好地方。

超过阈值时，自动真空执行真空和分析。阈值如下：

• autovacuum_vacuum_threshold + autovacuum_vacuum_scale_factor * 行
• autovacuum_analyze_threshold + autovacuum_analyze_scale_factor * 行

在 PostgreSQL 中，有没有办法在保持 Auto Vacuum 的 Vacuum 自动运行的同时停止分析？

我是使用 posgtresql 的新手，我想在 dead_rows 很高时进行自动清理。

我怎样才能自动做到这一点。

谢谢，

PostgreSQL 数据库错误日志整天生成这个错误并且仍然继续错误到第二天

错误涉及系统目录 ( pg_catalog.pg_largeobject, pg_catalog.pg_largeobject_metadata)。

我需要有关如何修复它的帮助，或者如果我在这两个表上禁用 autovacuum 会受到什么影响。

笔记：

• 数据库：PostgreSQL 版本 11.6
• 操作系统：Red Hat Enterprise Linux Server 7.8 版

我对 postgres autovacuum 设置进行了许多更改，例如更改 cost_delay 和 naptime 设置。我不确定我的所有更改是什么——并且想将 autovacuum 设置重置为默认设置。

有没有我可以执行的命令将它们恢复为默认值？

我有一个关于 Postgres autovacuum / Vacuum 设置的问题。我有一个包含 45 亿行的表，并且有一段时间进行了大量更新，导致大约 15 亿个死元组。此时 autovacuum 需要很长时间（几天）才能完成。在查看 pg_stat_progress_vacuum 视图时，我注意到：

导致多次索引重新扫描（index_vacuum_count）
根据文档- max_dead_tuples 是我们可以在需要执行索引真空周期之前存储的死元组数量，基于maintenance_work_mem。
据此，一个死元组需要 6 个字节的空间。
所以 6B x 178956970 = ~1GB
但我的设置是

那么我错过了什么？为什么我所有的 1.5b 死元组都不适合 max_dead_tuples，因为 20GB 应该提供足够的空间，为什么需要多次运行？

我寻找一种用计算机控制我的 CybovacE31 的方法，以将其集成到家庭自动化系统中。我知道它与 google home 和 Alexa 兼容，但我找不到使用的协议。你知道怎么做吗？谢谢。

我的真空吸尘器：https ://kyvol.com/products/cybovac-e31

我们注意到我们的一个表在 PG 12 上显着增长。这个表是非常频繁更新的目标，混合了列类型，包括一个非常大的text列（通常包含超过 50kb 的数据）——我们运行一个本地 cron查找早于 X 时间的行并将text列设置为空值的作业（因为在 X 时间后我们不再需要该特定列的数据）。

我们知道，由于 MVCC 模型，这实际上并没有释放磁盘空间，但我们希望 auto-vacuum 能够解决这个问题。令我们惊讶的是，在没有自动真空运行的情况下，该表继续增长（现在超过 40GB）。手动运行真空已经解决了这个问题，我们不再看到增长。

这导致我调查其他表，我意识到我根本不了解自动真空是如何触发的。

这是我对其工作原理的理解，希望有人可以将其分开：

• 我寻找其中有大量死元组的表： select * from pg_stat_all_tables ORDER BY n_dead_tup desc;
• 我认同tableX33169557 个死元组（n_dead_tup 列）。
• 我运行 aselect * from pg_class ORDER BY reltuples desc;来检查表上有多少估计行tableX
• 我通过列识别了 1725253 行reltuples。
• 我确认我的 autovacuum 设置：autovacuum_vacuum_threshold = 50和autovacuum_vacuum_scale_factor = 0.2
• 我应用公式threshold + pg_class.reltuples * scale_factor，所以，50 + 1725253 * 0.2它返回 345100.6

据我了解，一旦找到 ~345100 个死元组，自动真空将在此表上启动。但是tableX已经达到了惊人的 33169557 个死元组！, 这个表上的 last_autovacuum 是在 2 月份。

欢迎任何澄清。

我遇到过几次我的读取查询被卡住了几个小时，并且在检查pg_stat_activity它时wait_event_type有IOWait. 每次发生这种情况时，都会在该表上运行一个活动的 autovacuum。该表是使用 pg_partman 的分区表，我使用的是 Postgres 11。

简化版查询

查询有一个索引，例如

我注意到 Postgres 14 对分区表（https://www.postgresql.org/docs/14/release-14.html）上的 autovacuum 进行了优化，这让我更加怀疑 autovacuum 确实是IOWait 的这个卡住/挂起查询

Autovacuum 现在分析分区表 (Yuzuko Hosoya, Álvaro Herrera)

来自分区的插入、更新和删除元组计数现在传播到它们的父表，因此 autovacuum 知道何时处理它们。

这可能是由自动真空引起的吗？

• 如果是，为什么？有没有办法避免这种情况？
• 如果不是，可能是什么原因？

编辑（1）添加表模式和解释计划

表架构

解释计划：https ://explain.depesz.com/s/y3YH