{
    "api_version": "1",
    "kind": "dse_post",
    "self": "https://update.dsesecurity.com/api/v1/posts/fence-the-former-postgresql-primary-before-accepting-failover/",
    "item": {
        "id": "https://update.dsesecurity.com/updates/fence-the-former-postgresql-primary-before-accepting-failover/",
        "slug": "fence-the-former-postgresql-primary-before-accepting-failover",
        "url": "https://update.dsesecurity.com/updates/fence-the-former-postgresql-primary-before-accepting-failover/",
        "alternate_urls": {
            "markdown": "https://update.dsesecurity.com/updates/fence-the-former-postgresql-primary-before-accepting-failover.md",
            "json": "https://update.dsesecurity.com/api/v1/posts/fence-the-former-postgresql-primary-before-accepting-failover/"
        },
        "title": "Fence the former PostgreSQL primary before accepting failover",
        "summary": "Make authority transfer and protection against a returning former primary part of failover acceptance.",
        "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:31+00:00",
        "modified_at": "2026-10-15T13:36:15+00:00",
        "reviewed_on": "2026-10-15",
        "reading_minutes": 2,
        "word_count": 240,
        "potentially_affected": "This applies to PostgreSQL 17 physical-standby failover design. It does not endorse a particular cluster manager, fencing device, network topology, or automatic failure-detection policy.",
        "dse_recommendation": "DSE recommends treating authority transfer, client redirection, former-primary exclusion, and restoration of redundancy as separate named steps.",
        "primary_source": {
            "name": "PostgreSQL 17 — Failover",
            "url": "https://www.postgresql.org/docs/17/warm-standby-failover.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>Make authority transfer and protection against a returning former primary part of failover acceptance.</p>\n<h2>Source facts</h2>\n<p>PostgreSQL 17 documentation requires a mechanism that prevents a restarted former primary from continuing to act as primary after failover. Otherwise, both servers can believe they are authoritative and data loss can follow. PostgreSQL itself does not provide the system software that detects a failed primary and notifies the standby. After promotion, redundancy also needs rebuilding: the new primary operates alone until a suitable standby has been recreated or rejoined.</p>\n<p>Source: <a href=\"https://www.postgresql.org/docs/17/warm-standby-failover.html\">PostgreSQL 17 — Failover</a>.</p>\n<h2>Applicability</h2>\n<p>This applies to PostgreSQL 17 physical-standby failover design. It does not endorse a particular cluster manager, fencing device, network topology, or automatic failure-detection policy.</p>\n<h2>DSE recommendation</h2>\n<p>DSE recommends treating authority transfer, client redirection, former-primary exclusion, and restoration of redundancy as separate named steps. Define who can approve promotion when failure is ambiguous. Keep a written route back to a protected two-server state, rather than ending the incident when the application reconnects. Include the behavior of a recovered old host in the design review, with a clear rule preventing it from accepting writes until its new role has been established.</p>\n<h2>Verification</h2>\n<p>In a controlled rehearsal, promote the standby and simulate the former primary returning. Verify that the excluded node cannot accept application writes, clients reach the intended primary, and a standby is restored afterward. Retain the observed authority transitions and any manual approvals in the rehearsal record.</p>\n<h2>Official reference</h2>\n<p><a href=\"https://www.postgresql.org/docs/17/warm-standby-failover.html\">PostgreSQL 17 — Failover</a>. Reviewed October 15, 2026.</p>",
        "content_text": "Make authority transfer and protection against a returning former primary part of failover acceptance.\nSource facts\nPostgreSQL 17 documentation requires a mechanism that prevents a restarted former primary from continuing to act as primary after failover. Otherwise, both servers can believe they are authoritative and data loss can follow. PostgreSQL itself does not provide the system software that detects a failed primary and notifies the standby. After promotion, redundancy also needs rebuilding: the new primary operates alone until a suitable standby has been recreated or rejoined.\nSource: PostgreSQL 17 — Failover.\nApplicability\nThis applies to PostgreSQL 17 physical-standby failover design. It does not endorse a particular cluster manager, fencing device, network topology, or automatic failure-detection policy.\nDSE recommendation\nDSE recommends treating authority transfer, client redirection, former-primary exclusion, and restoration of redundancy as separate named steps. Define who can approve promotion when failure is ambiguous. Keep a written route back to a protected two-server state, rather than ending the incident when the application reconnects. Include the behavior of a recovered old host in the design review, with a clear rule preventing it from accepting writes until its new role has been established.\nVerification\nIn a controlled rehearsal, promote the standby and simulate the former primary returning. Verify that the excluded node cannot accept application writes, clients reach the intended primary, and a standby is restored afterward. Retain the observed authority transitions and any manual approvals in the rehearsal record.\nOfficial reference\nPostgreSQL 17 — Failover. Reviewed October 15, 2026.",
        "content_markdown": "Make authority transfer and protection against a returning former primary part of failover acceptance.\n\n## Source facts\n\nPostgreSQL 17 documentation requires a mechanism that prevents a restarted former primary from continuing to act as primary after failover. Otherwise, both servers can believe they are authoritative and data loss can follow. PostgreSQL itself does not provide the system software that detects a failed primary and notifies the standby. After promotion, redundancy also needs rebuilding: the new primary operates alone until a suitable standby has been recreated or rejoined.\n\nSource: [PostgreSQL 17 — Failover](https://www.postgresql.org/docs/17/warm-standby-failover.html).\n\n## Applicability\n\nThis applies to PostgreSQL 17 physical-standby failover design. It does not endorse a particular cluster manager, fencing device, network topology, or automatic failure-detection policy.\n\n## DSE recommendation\n\nDSE recommends treating authority transfer, client redirection, former-primary exclusion, and restoration of redundancy as separate named steps. Define who can approve promotion when failure is ambiguous. Keep a written route back to a protected two-server state, rather than ending the incident when the application reconnects. Include the behavior of a recovered old host in the design review, with a clear rule preventing it from accepting writes until its new role has been established.\n\n## Verification\n\nIn a controlled rehearsal, promote the standby and simulate the former primary returning. Verify that the excluded node cannot accept application writes, clients reach the intended primary, and a standby is restored afterward. Retain the observed authority transitions and any manual approvals in the rehearsal record.\n\n## Official reference\n\n[PostgreSQL 17 — Failover](https://www.postgresql.org/docs/17/warm-standby-failover.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/fence-the-former-postgresql-primary-before-accepting-failover/",
                "url": "https://update.dsesecurity.com/updates/fence-the-former-postgresql-primary-before-accepting-failover/",
                "isPartOf": {
                    "@id": "https://update.dsesecurity.com/#website"
                },
                "lastReviewed": "2026-10-15"
            },
            {
                "@type": "BreadcrumbList",
                "@id": "https://update.dsesecurity.com/updates/fence-the-former-postgresql-primary-before-accepting-failover/#breadcrumbs",
                "itemListElement": [
                    {
                        "@type": "ListItem",
                        "position": 1,
                        "name": "DSE Updates",
                        "item": "https://update.dsesecurity.com/"
                    },
                    {
                        "@type": "ListItem",
                        "position": 2,
                        "name": "Fence the former PostgreSQL primary before accepting failover",
                        "item": "https://update.dsesecurity.com/updates/fence-the-former-postgresql-primary-before-accepting-failover/"
                    }
                ]
            },
            {
                "@type": [
                    "Article",
                    "TechArticle"
                ],
                "@id": "https://update.dsesecurity.com/updates/fence-the-former-postgresql-primary-before-accepting-failover/#article",
                "identifier": "https://update.dsesecurity.com/updates/fence-the-former-postgresql-primary-before-accepting-failover/",
                "url": "https://update.dsesecurity.com/updates/fence-the-former-postgresql-primary-before-accepting-failover/",
                "headline": "Fence the former PostgreSQL primary before accepting failover",
                "description": "Make authority transfer and protection against a returning former primary part of failover acceptance.",
                "abstract": "Make authority transfer and protection against a returning former primary part of failover acceptance.",
                "articleBody": "Make authority transfer and protection against a returning former primary part of failover acceptance.\nSource facts\nPostgreSQL 17 documentation requires a mechanism that prevents a restarted former primary from continuing to act as primary after failover. Otherwise, both servers can believe they are authoritative and data loss can follow. PostgreSQL itself does not provide the system software that detects a failed primary and notifies the standby. After promotion, redundancy also needs rebuilding: the new primary operates alone until a suitable standby has been recreated or rejoined.\nSource: PostgreSQL 17 — Failover.\nApplicability\nThis applies to PostgreSQL 17 physical-standby failover design. It does not endorse a particular cluster manager, fencing device, network topology, or automatic failure-detection policy.\nDSE recommendation\nDSE recommends treating authority transfer, client redirection, former-primary exclusion, and restoration of redundancy as separate named steps. Define who can approve promotion when failure is ambiguous. Keep a written route back to a protected two-server state, rather than ending the incident when the application reconnects. Include the behavior of a recovered old host in the design review, with a clear rule preventing it from accepting writes until its new role has been established.\nVerification\nIn a controlled rehearsal, promote the standby and simulate the former primary returning. Verify that the excluded node cannot accept application writes, clients reach the intended primary, and a standby is restored afterward. Retain the observed authority transitions and any manual approvals in the rehearsal record.\nOfficial reference\nPostgreSQL 17 — Failover. Reviewed October 15, 2026.",
                "datePublished": "2026-10-15T13:32:31+00:00",
                "dateModified": "2026-10-15T13:36:15+00:00",
                "mainEntityOfPage": {
                    "@id": "https://update.dsesecurity.com/updates/fence-the-former-postgresql-primary-before-accepting-failover/"
                },
                "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/fence-the-former-postgresql-primary-before-accepting-failover/#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": "Fence the former PostgreSQL primary before accepting failover"
                },
                "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": 240,
                "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 — Failover",
                    "url": "https://www.postgresql.org/docs/17/warm-standby-failover.html"
                }
            }
        ]
    }
}