/* sorun su: standby server da BI ekibi sorgu cekerken, master daki vacuum eskimis transaction kuyruklarini silmekte, bu yüzden slave sorgu uzun surunce, conflicte dusmekte. Cunku aradigi veri, artik master tarafta silindiginden,erisememktedir. Cozum asagida yazili ancak COZUMU UYGULARKEN master TARAFTA BLOAT OLUSTURABILIYOR!!! */
ERROR: canceling statement due to conflict with recovery Detail: User query might have needed to see row versions that must be removed
hot_standby_feedback can prevent replication conflicts To solve this kind of problem, we can teach the standby to periodically inform the primary about the oldest transaction running on the standby. If the primary knows about old transactions on the standby, it can make VACUUM keep rows until the standbys are done. This is exactly what hot_standby_feedback does. It prevents rows from being deleted too early from a standby’s point of view. The idea is to inform the primary about the oldest transaction ID on the standby so that VACUUM can delay its cleanup action for certain rows.
The benefit is obvious: hot_standby_feedback will dramatically reduce the number of replication conflicts.
Disadvantages: However, there are also downsides: Remember, VACUUM will delay its cleanup operations. If the standby never terminates a query, it can lead to table bloat on the primary, which can be dangerous in the long run.
