Repository navigation
skip TIMELINE_HISTORY on the logical replication connection - #64
Merged
Merged
Conversation
Nothing read the timeline history. The rows filled IdentifySystem.currentTimeline, which no code reads, so the parser, the catalog table and the cdcPathDir plumbing that fed them are all removed. pgsql_identify_system loses its third parameter. In place of the collection, stream_write_context now compares the source timeline against the one recorded for this migration and stops when they differ. A promotion or a point-in-time restore forks the source history, and changes already applied to the target may belong to a branch the new source does not have. The check reads the timeline that IDENTIFY_SYSTEM already returns, so it needs no extra replication command and works on managed providers that restrict TIMELINE_HISTORY. The recorded timeline is left in place on failure so the operator can see both values. The cdc-low-level suite covers the new path.
Collaborator
|
This most recent commit finishes the removal (the parser, the catalog table and the cdcPathDir plumbing were all unreachable once the command goes, and parseTimelineHistoryResult was emitting an unused-function warning), and replaces the collection with a check: stream_write_context now compares the source timeline against the one recorded for the migration and stops when they differ, which catches a promoted or restored source without needing TIMELINE_HISTORY. Covered by a new case in cdc-low-level — no new containers, and I confirmed it fails without the check. Full battery green at PG18, style and banned-API checks pass. |
teknogeek0
approved these changes
Sep 28, 2026
teknogeek0
left a comment
Collaborator
There was a problem hiding this comment.
Reviewed in depth and approved from my side.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
On some Managed PostgreSQL (incl. Azure), CDC fails whenever the source is on a timeline > 1. That happens after an HA failover, a point-in-time restore, or a major-version upgrade.
pgsql_identify_system()followsIDENTIFY_SYSTEMwithTIMELINE_HISTORY <tli>on the logical replication connection. Azure rejects it:Stock PostgreSQL allows this command in logical walsender mode; Azure restricts it. Prefetch keeps reconnecting and failing the same way, transform gives up after 10s with
Failed to read stream context file: retry policy expired, and the follow pipeline exits with code 12. The initial copy completes, but no changes are replicated.Fix
Stop sending
TIMELINE_HISTORY, and remove the matchingparse_timeline_history_file()call instream_write_context(). Without the history filename, that call would fail on its own.This is safe because the history is never used:
IDENTIFY_SYSTEM.system->currentTimeline, and nothing reads that.catalog_lookup_timeline_history()already handles the empty table, which is also the normal case for timeline-1 sources.The helper functions and the
timeline_historycatalog table stay in place, so existing work directories and--resumeare unaffected. The now-unused staticparseTimelineHistoryResult()produces one-Wunused-functionwarning.Upstream issue: dimitri#1039 (open, not fixed upstream).