{
    "api_version": "1",
    "kind": "dse_post",
    "self": "https://update.dsesecurity.com/api/v1/posts/set-replica-identity-before-publishing-postgresql-updates-and-deletes/",
    "item": {
        "id": "https://update.dsesecurity.com/updates/set-replica-identity-before-publishing-postgresql-updates-and-deletes/",
        "slug": "set-replica-identity-before-publishing-postgresql-updates-and-deletes",
        "url": "https://update.dsesecurity.com/updates/set-replica-identity-before-publishing-postgresql-updates-and-deletes/",
        "alternate_urls": {
            "markdown": "https://update.dsesecurity.com/updates/set-replica-identity-before-publishing-postgresql-updates-and-deletes.md",
            "json": "https://update.dsesecurity.com/api/v1/posts/set-replica-identity-before-publishing-postgresql-updates-and-deletes/"
        },
        "title": "Set replica identity before publishing PostgreSQL updates and deletes",
        "summary": "Check row-identification readiness before accepting a publication that must carry updates and deletes.",
        "format": {
            "slug": "guide",
            "name": "Guide"
        },
        "priority": {
            "slug": "info",
            "name": "Information"
        },
        "featured": false,
        "image": {
            "theme": "identity-cloud",
            "label": "Identity & cloud",
            "alt": "Governed cloud identity system with connected service and lifecycle nodes.",
            "card_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-card.webp?v=1.8.20",
            "hero_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-hero.webp?v=1.8.20",
            "social_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-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:33+00:00",
        "modified_at": "2026-10-15T13:36:15+00:00",
        "reviewed_on": "2026-10-15",
        "reading_minutes": 2,
        "word_count": 243,
        "potentially_affected": "This applies to PostgreSQL 17 publication design for logical replication. It addresses row identification, rather than the separate schema synchronization or sequence handover requirements.",
        "dse_recommendation": "DSE recommends reviewing every published table against its actual application operations before enabling the publication.",
        "primary_source": {
            "name": "PostgreSQL 17 — Publication",
            "url": "https://www.postgresql.org/docs/17/logical-replication-publication.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": "<p>Check row-identification readiness before accepting a publication that must carry updates and deletes.</p>\n<h2>Source facts</h2>\n<p>PostgreSQL 17 publications need a table replica identity to replicate UPDATE and DELETE operations. A primary key normally supplies it; a qualifying unique index or REPLICA IDENTITY FULL can be used in other cases. Without a suitable identity, those operations can fail on the publisher even though inserts still work. FULL uses the whole row and can cause inefficient subscriber searches when no suitable index is available. Publication membership alone does not establish update readiness.</p>\n<p>Source: <a href=\"https://www.postgresql.org/docs/17/logical-replication-publication.html\">PostgreSQL 17 — Publication</a>.</p>\n<h2>Applicability</h2>\n<p>This applies to PostgreSQL 17 publication design for logical replication. It addresses row identification, rather than the separate schema synchronization or sequence handover requirements.</p>\n<h2>DSE recommendation</h2>\n<p>DSE recommends reviewing every published table against its actual application operations before enabling the publication. Record the selected identity and the matching subscriber arrangement. Avoid making FULL the automatic answer for every keyless table; ask the database designer whether an appropriate key is possible and how subscriber lookup cost will be evaluated. Include update and delete behavior in the deployment acceptance plan, even when the initial data copy and insert-only demonstration have already succeeded.</p>\n<h2>Verification</h2>\n<p>In a test subscription, exercise inserts, updates, and deletes for each intended identity pattern. Inspect publisher errors and subscriber results, and compare representative lookup behavior where FULL is proposed. Retain the reviewed table list and identify any tables intentionally published only for supported operations.</p>\n<h2>Official reference</h2>\n<p><a href=\"https://www.postgresql.org/docs/17/logical-replication-publication.html\">PostgreSQL 17 — Publication</a>. Reviewed October 15, 2026.</p>",
        "content_text": "Check row-identification readiness before accepting a publication that must carry updates and deletes.\nSource facts\nPostgreSQL 17 publications need a table replica identity to replicate UPDATE and DELETE operations. A primary key normally supplies it; a qualifying unique index or REPLICA IDENTITY FULL can be used in other cases. Without a suitable identity, those operations can fail on the publisher even though inserts still work. FULL uses the whole row and can cause inefficient subscriber searches when no suitable index is available. Publication membership alone does not establish update readiness.\nSource: PostgreSQL 17 — Publication.\nApplicability\nThis applies to PostgreSQL 17 publication design for logical replication. It addresses row identification, rather than the separate schema synchronization or sequence handover requirements.\nDSE recommendation\nDSE recommends reviewing every published table against its actual application operations before enabling the publication. Record the selected identity and the matching subscriber arrangement. Avoid making FULL the automatic answer for every keyless table; ask the database designer whether an appropriate key is possible and how subscriber lookup cost will be evaluated. Include update and delete behavior in the deployment acceptance plan, even when the initial data copy and insert-only demonstration have already succeeded.\nVerification\nIn a test subscription, exercise inserts, updates, and deletes for each intended identity pattern. Inspect publisher errors and subscriber results, and compare representative lookup behavior where FULL is proposed. Retain the reviewed table list and identify any tables intentionally published only for supported operations.\nOfficial reference\nPostgreSQL 17 — Publication. Reviewed October 15, 2026.",
        "content_markdown": "Check row-identification readiness before accepting a publication that must carry updates and deletes.\n\n## Source facts\n\nPostgreSQL 17 publications need a table replica identity to replicate UPDATE and DELETE operations. A primary key normally supplies it; a qualifying unique index or REPLICA IDENTITY FULL can be used in other cases. Without a suitable identity, those operations can fail on the publisher even though inserts still work. FULL uses the whole row and can cause inefficient subscriber searches when no suitable index is available. Publication membership alone does not establish update readiness.\n\nSource: [PostgreSQL 17 — Publication](https://www.postgresql.org/docs/17/logical-replication-publication.html).\n\n## Applicability\n\nThis applies to PostgreSQL 17 publication design for logical replication. It addresses row identification, rather than the separate schema synchronization or sequence handover requirements.\n\n## DSE recommendation\n\nDSE recommends reviewing every published table against its actual application operations before enabling the publication. Record the selected identity and the matching subscriber arrangement. Avoid making FULL the automatic answer for every keyless table; ask the database designer whether an appropriate key is possible and how subscriber lookup cost will be evaluated. Include update and delete behavior in the deployment acceptance plan, even when the initial data copy and insert-only demonstration have already succeeded.\n\n## Verification\n\nIn a test subscription, exercise inserts, updates, and deletes for each intended identity pattern. Inspect publisher errors and subscriber results, and compare representative lookup behavior where FULL is proposed. Retain the reviewed table list and identify any tables intentionally published only for supported operations.\n\n## Official reference\n\n[PostgreSQL 17 — Publication](https://www.postgresql.org/docs/17/logical-replication-publication.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/set-replica-identity-before-publishing-postgresql-updates-and-deletes/",
                "url": "https://update.dsesecurity.com/updates/set-replica-identity-before-publishing-postgresql-updates-and-deletes/",
                "isPartOf": {
                    "@id": "https://update.dsesecurity.com/#website"
                },
                "lastReviewed": "2026-10-15"
            },
            {
                "@type": "BreadcrumbList",
                "@id": "https://update.dsesecurity.com/updates/set-replica-identity-before-publishing-postgresql-updates-and-deletes/#breadcrumbs",
                "itemListElement": [
                    {
                        "@type": "ListItem",
                        "position": 1,
                        "name": "DSE Updates",
                        "item": "https://update.dsesecurity.com/"
                    },
                    {
                        "@type": "ListItem",
                        "position": 2,
                        "name": "Set replica identity before publishing PostgreSQL updates and deletes",
                        "item": "https://update.dsesecurity.com/updates/set-replica-identity-before-publishing-postgresql-updates-and-deletes/"
                    }
                ]
            },
            {
                "@type": [
                    "Article",
                    "TechArticle"
                ],
                "@id": "https://update.dsesecurity.com/updates/set-replica-identity-before-publishing-postgresql-updates-and-deletes/#article",
                "identifier": "https://update.dsesecurity.com/updates/set-replica-identity-before-publishing-postgresql-updates-and-deletes/",
                "url": "https://update.dsesecurity.com/updates/set-replica-identity-before-publishing-postgresql-updates-and-deletes/",
                "headline": "Set replica identity before publishing PostgreSQL updates and deletes",
                "description": "Check row-identification readiness before accepting a publication that must carry updates and deletes.",
                "abstract": "Check row-identification readiness before accepting a publication that must carry updates and deletes.",
                "articleBody": "Check row-identification readiness before accepting a publication that must carry updates and deletes.\nSource facts\nPostgreSQL 17 publications need a table replica identity to replicate UPDATE and DELETE operations. A primary key normally supplies it; a qualifying unique index or REPLICA IDENTITY FULL can be used in other cases. Without a suitable identity, those operations can fail on the publisher even though inserts still work. FULL uses the whole row and can cause inefficient subscriber searches when no suitable index is available. Publication membership alone does not establish update readiness.\nSource: PostgreSQL 17 — Publication.\nApplicability\nThis applies to PostgreSQL 17 publication design for logical replication. It addresses row identification, rather than the separate schema synchronization or sequence handover requirements.\nDSE recommendation\nDSE recommends reviewing every published table against its actual application operations before enabling the publication. Record the selected identity and the matching subscriber arrangement. Avoid making FULL the automatic answer for every keyless table; ask the database designer whether an appropriate key is possible and how subscriber lookup cost will be evaluated. Include update and delete behavior in the deployment acceptance plan, even when the initial data copy and insert-only demonstration have already succeeded.\nVerification\nIn a test subscription, exercise inserts, updates, and deletes for each intended identity pattern. Inspect publisher errors and subscriber results, and compare representative lookup behavior where FULL is proposed. Retain the reviewed table list and identify any tables intentionally published only for supported operations.\nOfficial reference\nPostgreSQL 17 — Publication. Reviewed October 15, 2026.",
                "datePublished": "2026-10-15T13:32:33+00:00",
                "dateModified": "2026-10-15T13:36:15+00:00",
                "mainEntityOfPage": {
                    "@id": "https://update.dsesecurity.com/updates/set-replica-identity-before-publishing-postgresql-updates-and-deletes/"
                },
                "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/set-replica-identity-before-publishing-postgresql-updates-and-deletes/#primaryimage",
                    "url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-social-v2.jpg?v=1.8.20",
                    "contentUrl": "https://update.dsesecurity.com/assets/editorial/identity-cloud-social-v2.jpg?v=1.8.20",
                    "width": 1200,
                    "height": 630,
                    "caption": "Set replica identity before publishing PostgreSQL updates and deletes"
                },
                "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": 243,
                "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 — Publication",
                    "url": "https://www.postgresql.org/docs/17/logical-replication-publication.html"
                }
            }
        ]
    }
}