<?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>Data-Loss on kylorend3r Blog</title><link>https://kylorend3r.github.io/tags/data-loss/</link><description>Recent content in Data-Loss 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, 02 Sep 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://kylorend3r.github.io/tags/data-loss/index.xml" rel="self" type="application/rss+xml"/><item><title>How a Successful pg_upgrade Silently Loses Your Logically Replicated Data</title><link>https://kylorend3r.github.io/posts/postgresql-subscriber-silent-row-loss-after-pg-upgrade/</link><pubDate>Wed, 02 Sep 2026 00:00:00 +0000</pubDate><guid>https://kylorend3r.github.io/posts/postgresql-subscriber-silent-row-loss-after-pg-upgrade/</guid><description>A pg_upgrade of a logical replication subscriber that reported success, a subscription that came back with a running apply worker and zero lag, and a few hundred committed rows that were received, discarded and acknowledged as applied. This is the operation, the symptom, the fix, and then the mechanism: an empty pg_subscription_rel, traced step by step through the apply worker source.</description></item></channel></rss>