Hello All,

In an attempt to offload some of the pressure off our master postgres node,
We recently decided to start running reports off of our hot-standby.

There is a desire for these reports to return fairly current data, so we have 
been monitoring the replication delay between the master -> standby.
We currently have max_standby_archive_delay and max_streaming_archive_delay set 
to -1, to avoid any timeouts in the application (when pulling reports).
hot_standby_feedback is enabled on the slave node, but we are not currently 
setting vacuum_defer_cleanup_age.

95% of the time, the delay is only microseconds. But we have discovered that 
whenever the master does an auto vacuum of a large table, the transaction 
replay delay can climb is high as 1 hour. These delays don’t seem to correlate 
with any particular queries that are running against the master or the standby, 
and the delay only subsides when the vacuum completes.

Does anyone have any recommendations for a configuration that can minimize the 
replay delays that occur during the vacuums of large tables.

--
Thank you,
Jeff McDowell
Email: jeff.mcdow...@panerabread.com

Reply via email to