<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Replication on BitPage</title><link>https://bitpage.me/tags/replication/</link><description>Recent content in Replication on BitPage</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Wed, 29 Jul 2026 06:43:03 +0000</lastBuildDate><atom:link href="https://bitpage.me/tags/replication/index.xml" rel="self" type="application/rss+xml"/><item><title>PostgreSQL conflict with recovery: why both standard fixes make it worse under Patroni</title><link>https://bitpage.me/databases/postgres-conflict-with-recovery-patroni-haproxy/</link><pubDate>Wed, 29 Jul 2026 06:43:03 +0000</pubDate><guid>https://bitpage.me/databases/postgres-conflict-with-recovery-patroni-haproxy/</guid><description>Short answer: Both top search results for canceling statement due to conflict with recovery are wrong on a Patroni cluster with replication slots and one replica. hot_standby_feedback=on parks the xmin horizon inside the slot, where it survives the replica&amp;rsquo;s death and bloats the primary; raising max_standby_streaming_delay converts held-back replay into the exact lag your load balancer ejects the replica for. What I shipped instead was removing on-marked-down shutdown-sessions from the read backend, after measuring that replica lag is 11.</description></item></channel></rss>