自从我有了一个新的基于ARM的M1 MacBook Pro以来，我一直遇到严重且一致的PostgreSQL问题(psql13.1)。无论我使用Rails服务器还是Foreman，我的浏览器和终端都会收到错误，如PG::InternalError: ERROR: could not read block 15 in file "base/147456/148555": Bad address、PG::Error (invalid encoding name: unicode)或Error during failsafe response: PG::UnableToSend: no connection to the server。奇怪的是，我经常可以反复刷新浏览器，以便让事情正常工作(直到它们不可避免地不再工作为止)。
我知道与基于ARM的M1 Mac相关的所有配置挑战，这就是为什么我以多种方式多次卸载和重新安装从Homebrew到Postgres的所有东西(有Rosetta，没有Rosetta，使用arch -x86_64 brew命令，使用Postgres应用程序而不是Homebrew安装)。我在随机留言板上遇到过其他几个人，他们也遇到了同样的问题(也在新款Mac电脑上)，但运气不佳，这就是为什么我不愿意相信这是一个驱动器腐败问题。(我也多次运行磁盘实用程序急救检查；它说一切都很健康，但我不知道这有多可靠。)
我正在使用thingbot奇偶校验来将我的开发环境数据库与当前生产中的数据库同步。当我运行development restore production时，我的终端中有数百行看起来像下面的输出(这是在下载完成后，但在创建默认值、处理数据、序列集等之前)。我相信这是问题的根源，但我不确定解决方案是什么：
pg_restore: dropping TABLE [table name1]
pg_restore: from TOC entry 442; 1259 15829269 TABLE [table name1] u1oi0d2o8cha8f
pg_restore: error: could not execute query: ERROR: table "[table name1]" does not exist
Command was: DROP TABLE "public"."[table name1]";
pg_restore: dropping TABLE [table name2]
pg_restore: from TOC entry 277; 1259 16955 TABLE [table name2] u1oi0d2o8cha8f
pg_restore: error: could not execute query: ERROR: table "[table name2]" does not exist
Command was: DROP TABLE "public"."[table name2]";
pg_restore: dropping TABLE [table name3]
pg_restore: from TOC entry 463; 1259 15830702 TABLE [table name3] u1oi0d2o8cha8f
pg_restore: error: could not execute query: ERROR: table "[table name3]" does not exist
Command was: DROP TABLE "public"."[table name3]";
pg_restore: dropping TABLE [table name4]
pg_restore: from TOC entry 445; 1259 15830421 TABLE [table name4] u1oi0d2o8cha8f
pg_restore: error: could not execute query: ERROR: table "[table name4]" does not exist
Command was: DROP TABLE "public"."[table name4]";
其他人经历过这种情况吗？任何解决方案都将不胜感激。谢谢
编辑：我在一台旧的MacBook Pro(也运行Big Sur)上复制了同样的问题，所以它似乎与M1无关，但可能与Big Sur。
此问题的最终解决方法：
在尝试了其他答案中的所有变通方法后，我仍然偶尔会出现这个错误。即使在转储和恢复数据库后，切换到M1原生postgres，运行各种维护脚本等。
在对postgresql.conf进行了大量修改后，唯一能无限期可靠地解决这个问题的东西(此后一直没有收到错误)：
在postgresql.conf中，更改：
max_worker_processes = 8
至
max_worker_processes = 1
在做了这个更改之后，我已经在以前错误百出的数据库中抛出了每个测试，但它一次也没有显示相同的错误。以前，我在一个约有20M条记录的数据库上运行的提取例程在处理了1-2百万条记录后会出现坏地址错误。现在它完成了整个过程。
显然，减少并行工作者的数量会对性能造成影响，但这是我找到的可靠且永久解决此问题的唯一方法。
更新#2：
WAL缓冲区等调整延长了错误之间的时间，但并没有完全消除。最终使用Homebrew重新安装了一个新的Apple Silicon版本的Postgres，然后对我现有的数据库进行pg_dump(遇到错误)，并将其恢复到新的安装/集群中。
这里有一个有趣的地方：pg_restore未能恢复数据库中的一个索引，并在恢复过程中注意到了这一点(否则将完成)。我的直觉是，这个索引的损坏或其他问题导致了Bad Address错误。因此，我对这个问题的最后建议是执行pg_dump，然后使用pg_restore，而不是pg_dump来恢复数据库。pg_restore似乎在pg_dump没有的地方标记了这个问题，编写了一个没有错误索引的干净DB。
更新：
在尝试了几个解决方案(包括完整的pg_dump和恢复受影响的数据库)后，仍然遇到此问题。虽然有些修复程序似乎延长了两次出现之间的时间(特别是增加共享缓冲区内存)，但没有一个被证明是永久性的修复程序。
也就是说，对postgres邮件列表的进一步挖掘表明；坏地址"；错误可能和WAL(预写日志)问题一起发生。因此，我现在在postgresql.conf文件中设置了以下内容，显著增加了WAL缓冲区的大小：
wal_buffers=4MB
从那以后就再也没有经历过这个问题(又是敲门砖)。
这将产生一些影响，这是有道理的，因为wal_buffer大小默认情况下与共享缓冲区大小成比例增加(如上所述，增加共享缓冲区提供了临时缓解)。不管怎样，在我们得到这个错误的确切原因之前，还需要尝试其他方法。
在M1 MacBook Air上偶尔会出现这种问题：ERROR: could not read block和Bad Address以各种排列。
我在postgres论坛上读到，这个问题可能发生在虚拟机设置中。因此，我认为这是罗塞塔造成的。即使您使用的是通用版本的postgres，您也可能仍在使用x86二进制文件作为某些辅助进程(例如，在我的案例中为Python)。
无论如何，以下是解决问题的方法(到目前为止)：重新索引数据库
注意：您需要从命令行重新索引，而不是使用SQL命令。当我尝试使用SQL重新索引时，我一次又一次地遇到相同的Bad Address错误，并且重新索引从未完成。
当我使用命令行重新索引时，过程结束了，Bad Address错误没有再次出现(敲木头)。
对我来说，这只是：
reindexdb name_of_database
12GB的数据库需要20-30分钟。我不仅不再收到这些错误，而且数据库似乎更容易启动。只希望这个问题不会在罗塞塔中重复读取/写入/创建索引。我不知道为什么这样。。。也许在M1 Mac上创建的索引容易损坏？也许由于罗塞塔的交互，索引由于写入或访问而损坏？
Big Sur Beta 11.3中有可能修复了这个问题吗
自从在我的Mac mini M1(现在在PostgreSQL 13.2上)上使用MacPorts安装PostgreSQL 13以来，我一直遇到与OP相同的问题
我会看到could not read block错误：
- 偶尔运行临时查询时
- 在R Markdown中编译一本进行多次查询的书时总是
-
在我的主数据库上运行
VACUUM FULL时总是(这台机器上的实例中大约有620 GB，相对于VACUUM FULL所需的时间，错误会很快抛出)
(到目前为止，我的"修复方案"是将我的Mac指向我在办公室角落里运行的Ubuntu服务器，所以对我来说没有真正的问题。)
但自从今天升级到Big Sur Beta 11.3后，我成功地完成了2和3，没有出现错误(在升级前都失败了)。有没有可能是操作系统中的某些东西修复了这个问题？
我从postgresql.conf.sample恢复了postgresql.conf(并重新启动了数据库服务器)，从那以后一切都很好。
TBC，我尝试了wal_buffers&max_worker_processes在这里，它没有帮助。我偶然发现了它，因为我尝试了很多事情，只需要回去。我没有重新初始化整个数据库或类似的东西，只是配置文件。