正如这里所说的关于hot_standby_feedback = on:

它的缺点是备用电脑会让主电脑膨胀， 这可能也会让一些人感到惊讶

在这里:

max_standby_streaming_delay的设置是什么?我宁愿 默认为-1，而不是默认的hot_standby_feedback。那样的话 你在待机时做的事只会影响待机

所以我补充道

max_standby_streaming_delay = -1

和没有更多的pg_dump错误为我们，也不是主膨胀:)

对于AWS RDS实例，请查看http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.html

同样，对于@max-malysh的精彩回答，这里还有第二个警告。

对于来自主服务器的事务的任何延迟应用程序，从者将拥有一个旧的、过时的数据视图。因此，虽然通过设置max_standby_archive_delay和max_standby_streaming_delay为追随者上的查询提供时间是有意义的，但要记住这两个注意事项:

追随者作为备用/备份的价值会降低 在追随者上运行的任何其他查询都可能返回过时的数据。

如果用于备份的关注者的值最终与托管查询冲突太多，那么一种解决方案是多个关注者，每个关注者都针对其中一个进行了优化。

另外，请注意，一行中的多个查询可能会导致wal条目的应用程序一直被延迟。因此，在选择新值时，不只是单个查询的时间，而是在冲突查询开始时启动一个移动窗口，并在wal条目最终应用时结束。

也许现在回答这个问题已经太迟了，但我们在制作过程中也面临着同样的问题。 之前我们只有一个RDS，随着应用端用户数量的增加，我们决定为它添加Read Replica。Read副本在登台时工作正常，但一旦我们转移到生产时，我们开始得到相同的错误。

所以我们通过在Postgres属性中启用hot_standby_feedback属性来解决这个问题。 我们参考了以下链接

https://aws.amazon.com/blogs/database/best-practices-for-amazon-rds-postgresql-replication/

我希望它能有所帮助。

在热备服务器上运行查询有点棘手——它可能会失败，因为在查询过程中，一些需要的行可能会在主服务器上更新或删除。由于主服务器不知道查询是在辅助服务器上启动的，所以它认为它可以清理(真空)旧版本的行。然后，secondary必须重播这个清理操作，并且必须强制取消所有可以使用这些行的查询。

较长的查询将更频繁地被取消。

您可以通过在主服务器上启动一个可重复的读事务来解决这个问题，该事务执行一个虚拟查询，然后在辅助服务器上运行一个真正的查询时处于空闲状态。它的存在将防止主目录上的旧行版本被清空。

文档中的“热备-处理查询冲突”一节详细介绍了这个主题和其他解决方法。

当一个长时间运行的查询正在运行时，热备从服务器上的表数据被修改。确保表数据不被修改的一个解决方案(PostgreSQL 9.1+)是暂停复制并在查询后恢复:

select pg_xlog_replay_pause(); -- suspend
select * from foo; -- your query
select pg_xlog_replay_resume(); --resume

不需要触摸hot_standby_feedback。正如其他人所提到的，将其设置为开启会导致腹胀。想象一下在一个slave上打开一个事务，而不是关闭它。

相反，将max_standby_archive_delay和max_standby_streaming_delay设置为一个合理的值:

# /etc/postgresql/10/main/postgresql.conf on a slave
max_standby_archive_delay = 900s
max_standby_streaming_delay = 900s

这样，对于持续时间小于900秒的slave的查询将不会被取消。如果您的工作负载需要更长的查询，只需将这些选项设置为更高的值。