我遇到了问题，需要一些建议。我通常是一名开发人员，但最近我公司的员工变动，我现在是唯一的IT人员，所以我不得不分支到很多未知的领域，真的需要一些帮助。
我们正在运行postgres 8.3。数据库正在尝试在大型对象表（pg_catalog.pg_large_object）上运行AUTO_VACUUM以防止事务ID环绕。我想我理解这意味着什么的基础知识。问题是，这个表是750G，有4.52亿行。 AUTO_VACUUM正在写入磁盘很多，占用磁盘空间（昨天消耗了我们最后250GB的1TB）。在紧急停机后，我们将恢复运行1100GB的空间和100GB的免费空间。但是，一旦postgres重新启动并运行，它就会再次启动AUTO_VACUUM流程。如果我终止该事务（我确定不建议这样做），它只会重新启动。
所以这是我的问题：
1）对于该表，完成AUTO_VACUUM过程需要多少空间？我该如何确定？
2）有没有更好的方法来配置服务器来处理这种情况，因此在需要时它不需要大量的磁盘空间？
3）如果不是2，你如何建议修复这个问题？
我不是DBA，并且没有Linux服务器管理经验，只是要求开发人员戴上很多帽子。我正在努力让DBA顾问帮助解决问题，但该公司正在推迟。尽管我付出了最大的努力，他们似乎并不了解问题的严重性。
连连呢？评论？您将提供的任何建议或指导将不胜感激。如果您需要更多信息，请与我们联系。
答案 0 :(得分：3)
如果您没有很快解决此问题，您的数据库将进入紧急关机以防止数据损坏，拒绝重新启动，直到txid环绕式vaccuum完成。检查日志以查看您与此点的接近程度，您会看到以下消息：
WARNING: database "mydb" must be vacuumed within 177009986 transactions
HINT: To avoid a database shutdown, execute a database-wide VACUUM in "mydb".
不要只是杀死真空并解决问题。除非你能承受一些意外停机，否则你真的需要解决这个问题。
它消耗大量磁盘空间的原因可能是您使用的是没有自动管理的freespacemap设置的旧版本，并且您可能已超过max_fsm_pages和/或{{1} }。检查日志，你可能会看到有关这些的消息。
不幸的是，你不能在事后提出这些障碍。这个旧的PostgreSQL安装已经失去了关于表中哪些空间是免费的知识。正确的清理和恢复将需要max_fsm_relations表，这需要至少与表+索引大小一样多的可用空间，并且在运行期间需要对表进行独占锁定
现在您正在接近强制txid环绕预防，大多数不那么具有干扰性的缓解选项（如CLUSTER）已不再对您开放。您最好的选择很可能是为autovacuum提供完成工作所需的空间 - 或者处理停机时间和pg_reorg然后CLUSTER表，以便更快地完成整个过程。
一旦恢复，我建议大幅增加VACUUM FREEZE并确保max_fsm_pages足够大。这些旧版本的大量调整建议就是搜索。
计划升级到9.2，自动管理自由空间地图（与任何版本8.4+一样）并具有各种autovac增强功能，以帮助阻止您首先进入这些泡菜。
如果遇到这种情况，请考虑与professional PostgreSQL support provider取得联系。 （正确披露：我为2ndQuadrant工作，其中一家是上市公司。）
答案 1 :(得分：2)
FreeNode #postgresql（IRC）的实时支持令人惊叹。经常有知识渊博的人醒着，可以谈论DBA /开发细节。我不能推荐它。