<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Subscription on kylorend3r Blog</title><link>https://kylorend3r.github.io/tags/subscription/</link><description>Recent content in Subscription on kylorend3r Blog</description><image><title>kylorend3r Blog</title><url>https://kylorend3r.github.io/og-image.png</url><link>https://kylorend3r.github.io/og-image.png</link></image><generator>Hugo -- 0.146.0</generator><language>en-us</language><lastBuildDate>Wed, 29 Jul 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://kylorend3r.github.io/tags/subscription/index.xml" rel="self" type="application/rss+xml"/><item><title>Upgrading a PostgreSQL Subscriber to Avoid Replaying WAL You Already Applied</title><link>https://kylorend3r.github.io/posts/upgrading-postgresql-logical-replication-subscribers-with-pg-upgrade/</link><pubDate>Wed, 29 Jul 2026 00:00:00 +0000</pubDate><guid>https://kylorend3r.github.io/posts/upgrading-postgresql-logical-replication-subscribers-with-pg-upgrade/</guid><description>&lt;p>&lt;strong>Summary:&lt;/strong> Running &lt;code>pg_upgrade&lt;/code> on a logical replication subscriber that&amp;rsquo;s older than PostgreSQL 17 silently drops the subscription&amp;rsquo;s replication origin — the bookmark tracking how far it has replayed. The publisher never finds out, so it replays WAL the subscriber already applied, surfacing as duplicate-key errors after an otherwise clean upgrade. This post covers why that happens, what PostgreSQL 17 changed to fix it, a manual procedure to protect subscribers on older versions, and the separate considerations for upgrading the publisher side, where publications survive the upgrade but replication slots never do.&lt;/p></description></item></channel></rss>