max_standby_streaming_delay（二）

作者：瀚高PG实验室 （Highgo PG Lab）- 天蝎座
前面博客提到了max_standby_archive_delay (integer)和max_standby_streaming_delay (integer) 两个参数。
对这两个参数有所了解以后，我们再考虑一下，即使再增大这两个参数，总有上限，而且增大这两个参数会导致主备数据库之间数据存在较多不一致。那么除了增大这两个参数的值外，还有什么解决办法？

答案是：hot_standby_feedback (boolean)

该参数更多的针对于前面博客提到的第三种情况：

主库上执行了vacuum操作, 这些被vacuum掉的tuple, 可能是standby库上的查询可见的TUPLE, 也会发生冲突.

Specifies whether or not a hot standby will send feedback to the
primary or upstream standby about queries currently executing on the
standby. This parameter can be used to eliminate query cancels caused
by cleanup records, but can cause database bloat on the primary for
some workloads. Feedback messages will not be sent more frequently
than once per wal_receiver_status_interval. The default value is off.
This parameter can only be set in the postgresql.conf file or on the
server command line.

If cascaded replication is in use the feedback is passed upstream
until it eventually reaches the primary. Standbys make no other use of
feedback they receive other than to pass upstream.

该参数打开后，会将有关当前在备用数据库上执行的查询的反馈发送给主数据库或上游备用数据库。 此参数可用于消除由清理记录造成的查询取消，但可能会导致某些工作负载较大的主服务器上的数据库膨胀。如果正在使用级联复制，则反馈会通过上游直到它最终到达主节点。 Standbys除了向上游传递信息外，不再使用他们收到的反馈。

以上的各种方式，不管是增大参数的值，还是开启hot_standby_feedback，都只能降低standby上SQL被cancel的概率，不能保证一定不会被cancel。

换一种思考方式，假如将max_standby_archive_delay 和max_standby_streaming_delay 的值修改为-1会怎样？请移步下篇博客 max_standby_streaming_delay（三）。