我正在努力解决Postgres的民间记忆问题。

民间传说

听说很久以前在一个遥远的星系（Ubuntu 12.04下的PostgreSQL 8.4），PostgreSQL经常遇到一个问题，如果承载服务器的机器出现故障（例如内核崩溃），当机器重新启动时，Postgres将启动，但数据库上的索引可能已损坏。例如

SELECT foo FROM bar WHERE baz = 123

会失败，因为上的索引bar.baz会损坏。重新索引表修复了问题，但由于无法检测到此问题，而且这是在设备环境中（手头没有 DBA），本质上为了防止这种情况，有必要在重新启动时重新索引所有表，这会非常昂贵。因此（推理是这样的）如果手头没有 DBA，使用 Postgres 是不明智的，特别是在表很大且计算索引昂贵的环境中。

由于这种民间传说，在这种情况下首选 MySQL。

我的理论

1. 我依稀记得在 8.4 下看到过​​这个问题，所以我认为其中有一些道理。

2. 我确信这也发生在 Ubuntu 14.0.4 下的 Postgres 9.3 上。我不知道它是否“经常”发生。它发生的系统正在运行（公认的旧）企业级 SAS 驱动器，该驱动器声称写入缓存已关闭，因此我认为这不是写入缓存问题。

3. 如果情况仍然如此，我想我可以在网上找到比我能找到的更多的证据。

4. 因此，我怀疑它可能已修复，或者可能是由于某些问题造成的postgresql.conf（尽管检查表明只有 autovacuum 设置从默认值更改）。

更多信息

1. 在我最近知道的系统中（使用 9.3）没有使用 LVM。存储系统是 ext4，安装在具有默认属性的物理驱动器上。这个驱动器是一个（公认的老）企业 SAS 驱动器加上 SAS1068 PCI-X Fusion-MPT SAS 控制器，它sdparm声称它没有打开写缓存，但这已经（据称）在不同供应商的多个驱动器上看到过等等。 ，虽然总是在 Ubuntu 上的 ext4 上。

2. fsync处于默认状态（on我相信）。

3. 没有主/从配置——只有一个主——（所以这不是multixact错误）。

4. 表是使用默认索引创建的（没有花哨的哈希索引）。

5. Postgres 会定期更新到任何相关的 Ubuntu LTS 版本。最新的问题是在 14.04。

问题

1. 系统崩溃后手动重建索引是一项预期任务吗？

2. 如果没有，是否曾经有过，什么时候改变过？

3. 是否可以避免手动重新索引的需要？