{ "api_version": "1", "kind": "dse_post", "self": "https://update.dsesecurity.com/api/v1/posts/plan-sequence-state-before-a-postgresql-logical-replication-handover/", "item": { "id": "https://update.dsesecurity.com/updates/plan-sequence-state-before-a-postgresql-logical-replication-handover/", "slug": "plan-sequence-state-before-a-postgresql-logical-replication-handover", "url": "https://update.dsesecurity.com/updates/plan-sequence-state-before-a-postgresql-logical-replication-handover/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/plan-sequence-state-before-a-postgresql-logical-replication-handover.md", "json": "https://update.dsesecurity.com/api/v1/posts/plan-sequence-state-before-a-postgresql-logical-replication-handover/" }, "title": "Plan sequence state before a PostgreSQL logical-replication handover", "summary": "Include sequence state and separately managed schema changes in a logical-replication handover.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "continuity-recovery", "label": "Continuity & recovery", "alt": "Paired infrastructure paths converging on a stable recovered service.", "card_url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "business-continuity", "name": "Business Continuity", "url": "https://update.dsesecurity.com/topic/business-continuity/" }, { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-10-15T13:32:32+00:00", "modified_at": "2026-10-15T13:36:15+00:00", "reviewed_on": "2026-10-15", "reading_minutes": 2, "word_count": 251, "potentially_affected": "This applies to PostgreSQL 17 logical replication when a subscriber may become writable. It does not describe physical streaming replication or claim that sequence adjustment alone completes a handover.", "dse_recommendation": "DSE recommends maintaining a handover checklist for sequence-backed columns and separately managed schema changes.", "primary_source": { "name": "PostgreSQL 17 — Logical Replication Restrictions", "url": "https://www.postgresql.org/docs/17/logical-replication-restrictions.html", "published_on": null, "authority": "www.postgresql.org" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "

Include sequence state and separately managed schema changes in a logical-replication handover.

\n

Source facts

\n

PostgreSQL 17 logical replication copies table data but does not replicate sequence state. Values already stored in serial or identity columns arrive with their rows; the subscriber’s sequence itself is not advanced by that replication. Database schema and DDL changes are also outside logical replication. Before using a subscriber as a writable replacement, the sequence values need updating appropriately, and schema changes need their own coordinated process. A read-only subscriber and a writable successor have different readiness requirements.

\n

Source: PostgreSQL 17 — Logical Replication Restrictions.

\n

Applicability

\n

This applies to PostgreSQL 17 logical replication when a subscriber may become writable. It does not describe physical streaming replication or claim that sequence adjustment alone completes a handover.

\n

DSE recommendation

\n

DSE recommends maintaining a handover checklist for sequence-backed columns and separately managed schema changes. Decide how writes will be stopped while the final source state is reconciled. Have the database owner approve the intended next-value behavior, including any application assumptions about generated identifiers. Keep a clear record of the authoritative data source and the point after which applications may write to the subscriber. Do not use matching row counts as the sole readiness decision.

\n

Verification

\n

Rehearse the planned handover with representative tables, including identity or serial columns. After reconciling state in the test environment, perform inserts and inspect generated identifiers and constraint behavior. Record schema differences and sequence adjustments explicitly before approving any equivalent production transition.

\n

Official reference

\n

PostgreSQL 17 — Logical Replication Restrictions. Reviewed October 15, 2026.

", "content_text": "Include sequence state and separately managed schema changes in a logical-replication handover.\nSource facts\nPostgreSQL 17 logical replication copies table data but does not replicate sequence state. Values already stored in serial or identity columns arrive with their rows; the subscriber’s sequence itself is not advanced by that replication. Database schema and DDL changes are also outside logical replication. Before using a subscriber as a writable replacement, the sequence values need updating appropriately, and schema changes need their own coordinated process. A read-only subscriber and a writable successor have different readiness requirements.\nSource: PostgreSQL 17 — Logical Replication Restrictions.\nApplicability\nThis applies to PostgreSQL 17 logical replication when a subscriber may become writable. It does not describe physical streaming replication or claim that sequence adjustment alone completes a handover.\nDSE recommendation\nDSE recommends maintaining a handover checklist for sequence-backed columns and separately managed schema changes. Decide how writes will be stopped while the final source state is reconciled. Have the database owner approve the intended next-value behavior, including any application assumptions about generated identifiers. Keep a clear record of the authoritative data source and the point after which applications may write to the subscriber. Do not use matching row counts as the sole readiness decision.\nVerification\nRehearse the planned handover with representative tables, including identity or serial columns. After reconciling state in the test environment, perform inserts and inspect generated identifiers and constraint behavior. Record schema differences and sequence adjustments explicitly before approving any equivalent production transition.\nOfficial reference\nPostgreSQL 17 — Logical Replication Restrictions. Reviewed October 15, 2026.", "content_markdown": "Include sequence state and separately managed schema changes in a logical-replication handover.\n\n## Source facts\n\nPostgreSQL 17 logical replication copies table data but does not replicate sequence state. Values already stored in serial or identity columns arrive with their rows; the subscriber’s sequence itself is not advanced by that replication. Database schema and DDL changes are also outside logical replication. Before using a subscriber as a writable replacement, the sequence values need updating appropriately, and schema changes need their own coordinated process. A read-only subscriber and a writable successor have different readiness requirements.\n\nSource: [PostgreSQL 17 — Logical Replication Restrictions](https://www.postgresql.org/docs/17/logical-replication-restrictions.html).\n\n## Applicability\n\nThis applies to PostgreSQL 17 logical replication when a subscriber may become writable. It does not describe physical streaming replication or claim that sequence adjustment alone completes a handover.\n\n## DSE recommendation\n\nDSE recommends maintaining a handover checklist for sequence-backed columns and separately managed schema changes. Decide how writes will be stopped while the final source state is reconciled. Have the database owner approve the intended next-value behavior, including any application assumptions about generated identifiers. Keep a clear record of the authoritative data source and the point after which applications may write to the subscriber. Do not use matching row counts as the sole readiness decision.\n\n## Verification\n\nRehearse the planned handover with representative tables, including identity or serial columns. After reconciling state in the test environment, perform inserts and inspect generated identifiers and constraint behavior. Record schema differences and sequence adjustments explicitly before approving any equivalent production transition.\n\n## Official reference\n\n[PostgreSQL 17 — Logical Replication Restrictions](https://www.postgresql.org/docs/17/logical-replication-restrictions.html). Reviewed October 15, 2026." }, "json_ld": { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://dsesecurity.com/#organization", "name": "Detection Systems & Engineering", "alternateName": "DSE Security", "url": "https://dsesecurity.com/", "logo": { "@type": "ImageObject", "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20" } }, { "@type": "Organization", "@id": "https://update.dsesecurity.com/#editorial-team", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/", "parentOrganization": { "@id": "https://dsesecurity.com/#organization" } }, { "@type": "WebSite", "@id": "https://update.dsesecurity.com/#website", "name": "DSE Updates", "alternateName": "DSE Security Knowledge Hub", "url": "https://update.dsesecurity.com/", "inLanguage": "en-US", "publisher": { "@id": "https://dsesecurity.com/#organization" }, "potentialAction": { "@type": "SearchAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}" }, "query-input": "required name=search_term_string" } }, { "@type": "WebPage", "@id": "https://update.dsesecurity.com/updates/plan-sequence-state-before-a-postgresql-logical-replication-handover/", "url": "https://update.dsesecurity.com/updates/plan-sequence-state-before-a-postgresql-logical-replication-handover/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-10-15" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/plan-sequence-state-before-a-postgresql-logical-replication-handover/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "Plan sequence state before a PostgreSQL logical-replication handover", "item": "https://update.dsesecurity.com/updates/plan-sequence-state-before-a-postgresql-logical-replication-handover/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/plan-sequence-state-before-a-postgresql-logical-replication-handover/#article", "identifier": "https://update.dsesecurity.com/updates/plan-sequence-state-before-a-postgresql-logical-replication-handover/", "url": "https://update.dsesecurity.com/updates/plan-sequence-state-before-a-postgresql-logical-replication-handover/", "headline": "Plan sequence state before a PostgreSQL logical-replication handover", "description": "Include sequence state and separately managed schema changes in a logical-replication handover.", "abstract": "Include sequence state and separately managed schema changes in a logical-replication handover.", "articleBody": "Include sequence state and separately managed schema changes in a logical-replication handover.\nSource facts\nPostgreSQL 17 logical replication copies table data but does not replicate sequence state. Values already stored in serial or identity columns arrive with their rows; the subscriber’s sequence itself is not advanced by that replication. Database schema and DDL changes are also outside logical replication. Before using a subscriber as a writable replacement, the sequence values need updating appropriately, and schema changes need their own coordinated process. A read-only subscriber and a writable successor have different readiness requirements.\nSource: PostgreSQL 17 — Logical Replication Restrictions.\nApplicability\nThis applies to PostgreSQL 17 logical replication when a subscriber may become writable. It does not describe physical streaming replication or claim that sequence adjustment alone completes a handover.\nDSE recommendation\nDSE recommends maintaining a handover checklist for sequence-backed columns and separately managed schema changes. Decide how writes will be stopped while the final source state is reconciled. Have the database owner approve the intended next-value behavior, including any application assumptions about generated identifiers. Keep a clear record of the authoritative data source and the point after which applications may write to the subscriber. Do not use matching row counts as the sole readiness decision.\nVerification\nRehearse the planned handover with representative tables, including identity or serial columns. After reconciling state in the test environment, perform inserts and inspect generated identifiers and constraint behavior. Record schema differences and sequence adjustments explicitly before approving any equivalent production transition.\nOfficial reference\nPostgreSQL 17 — Logical Replication Restrictions. Reviewed October 15, 2026.", "datePublished": "2026-10-15T13:32:32+00:00", "dateModified": "2026-10-15T13:36:15+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/plan-sequence-state-before-a-postgresql-logical-replication-handover/" }, "inLanguage": "en-US", "isAccessibleForFree": true, "author": { "@type": "Organization", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "@id": "https://dsesecurity.com/#organization" }, "image": { "@type": "ImageObject", "@id": "https://update.dsesecurity.com/updates/plan-sequence-state-before-a-postgresql-logical-replication-handover/#primaryimage", "url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-social-v2.jpg?v=1.8.20", "contentUrl": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-social-v2.jpg?v=1.8.20", "width": 1200, "height": 630, "caption": "Plan sequence state before a PostgreSQL logical-replication handover" }, "articleSection": [ "Business Continuity", "IT" ], "keywords": [ "Business Continuity", "IT", "Guide", "Information priority" ], "genre": "Guide", "about": [ { "@type": "Thing", "name": "Business Continuity", "url": "https://update.dsesecurity.com/topic/business-continuity/" }, { "@type": "Thing", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "wordCount": 251, "timeRequired": "PT2M", "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usageInfo": "https://update.dsesecurity.com/usage/", "copyrightHolder": { "@id": "https://dsesecurity.com/#organization" }, "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "citation": { "@type": "CreativeWork", "name": "PostgreSQL 17 — Logical Replication Restrictions", "url": "https://www.postgresql.org/docs/17/logical-replication-restrictions.html" } } ] } }