我最近有几个数据库需要维护。我刚刚提出这个“防止事务 ID 环绕失败”。我检查了我的数据库并得到了数字：
我在这个数据库上做了vacuumdb -a -v，然后得到了数字：
在我看来还不够好？我应该担心吗？
如果我对 PostgreSQL 手册的理解正确，我应该使用真空冻结将计数器重置为零吗？我知道这个数据库会稳定增长，通常是在插入时，而不是在删除/更新时。
谢谢你。
我有一台主服务器，另外两台服务器正在从主服务器复制。
我在主服务器上获得了完整的磁盘空间（我有一个archive_command将 wal 档案放入/wal_archive/目录中）。
它已满，PostgreSQL 日志显示错误：
archive command failed:
2019-06-04 09:52:49.079 EEST [3365] LOG: archive command failed with exit code 1
2019-06-04 09:52:49.079 EEST [3365] DETAIL: The failed archive command was: test ! -f /wal_archive/000000010000028C0000003B && cp pg_xlog/000000010000028C0000003B /wal_archive/000000010000028C0000003B
我用 清理了/wal_archive/目录pg_archivecleanup，但 PostgreSQL 仍然抛出同样的错误。
我试图重新加载 PostgreSQL 配置而不更改配置本身并且不使用以下命令重新启动：
/etc/init.d/postgresql reload
但还是一样，在日志中，PostgreSQL 会抛出一个错误。我应该如何恢复 wal_archive 复制到 wal_archive 目录？
我是否应该更改archive_command为true、重新加载并将存档再次更改回原始文件？
我试图避免重新启动服务器本身。
我刚刚从 Postgres 9.4 迁移到 10 数据库。如何验证一切是否正常？
我试图查看巨大的表格，行是不同的（不知何故在 Postgres 10 中比 9.4 中的行更多）
PSQL 9.4: 14 583 936
PSQL 10: 14 880 545
这是我的 pg_dump 和 pg_restore 命令，它们执行时没有错误，但是过程很长，转储是 12 小时，而 pg_restore 是 10 小时：
pg_dump -U postgres -d hive -Z1 -Fc -f /mnt/offline_backups/hive_full_2019-03-01_1630.dmp 2> /mnt/offline_backups/hive_full_2019-03-01_1630.log
pg_restore -U postgres -d hive -v /mnt/offline_backups/hive_full_2019-03-01_1630.dmp
这两个命令都没有任何错误。
以下是 pgadmin 4v 的一些截图：
在这两个数据库中，我只是按降序对行数进行排序。
如您所见，插入的行非常不同。
这是摘要：
我们正在尝试将所有数据库数据移动到其他位置。我们选择执行 pg_dump 并且遇到了一些问题：
首先是内存不足问题：在 pg_dump 初始化期间我们得到一个错误：
pg_dump: saving search_path =
pg_dump: saving database definition
out of memory
然后我们给 VM +16GB 的 RAM，所以总共 24GB，pg_dump 进程通过了它，现在我们有另一个问题：
pg_dump: dumping contents of table lob_messages
Write failed: Connection reset by peer
gumul@IT-dep:~$
到目前为止，错误只发生在这个“lob_messages”表上，这个表很大——pgAdmin 显示 256GB 大小。我已经尝试过 pg_dump 所有数据库，在那个错误之后我只在那个确切的表上尝试过 pg_dump。错误仍然发生。
我们正在使用 Postgesql 9,4。我们的系统管理员不知道这个问题。这是 htop 视图：
这是 df -h 视图：
我试图在 /mnt 挂载的 NAS 存储上以及本地 /var/lib/postgresql/9.4/main 中制作 pg_dump 文件
这是 postgresql.conf 更改的设置：
错误仍然存在。你能分享一些我做错的智慧吗？在那个错误期间（连接被对等重置）我从服务器断开连接，但只在运行 pg_dump 的那个会话上。在该错误期间，在其他连接（监控 htop）上保持连接。
我的 PostgreSQL 服务器有问题。
我从我以前的同事那里接管了 PostgreSQL 服务器，今天我的服务器由于 wal_archives 填满了磁盘空间而崩溃了。
通常 wal 段被放在根目录/wal_archive/中，我检查了它 - 它是空的。前段时间我检查了它，它有一些片段......
我深入挖掘并发现所有 wal 段都存储在pg_data/pg_xlog目录中。
这怎么可能发生？虽然postgresql.conf是这样设置的（仅显示“预写日志”行的启用段）
wal_level = hot_standby # minimal, archive, hot_standby, or
archive_mode = on # allows archiving to be done
archive_command = 'test ! -f /wal_archive/%f && cp %p /wal_archive/%f'
为什么我的 wal_archive 目录现在是空的，而配置设置显示不同的信息？
该wal_archive目录由 root 用户
pg_hba.conf文件拥有，没有任何复制用户 - 我假设服务器上也没有复制。没有像recovery.conf任何地方一样的文件。
cp：无法统计 'pg_xlog/000000010000033C00000081'：没有这样的文件或目录
2018-12-05 14:37:54 EET [7540-1860] 日志：存档命令失败，退出代码为 1
2018-12-05 14:37:54 EET [7540-1861] 详细信息：失败的存档命令是：测试！-f /wal_archive/000000010000033C00000081 && cp pg_xlog/000000010000033C00000081 /wal_archive/000000010000033C00000081
2018-12-05 14:37:54 EET [7540-1862] WARNING: archiving transaction log file "000000010000033C00000081" failed too many times, will try again later
同样由于恐慌，我不小心删除了 xlog 目录中的大块 wal 段，以启动服务器。现在一切正常，但我想确保将来不会有任何问题。