# Fence the former PostgreSQL primary before accepting failover

> Make authority transfer and protection against a returning former primary part of failover acceptance.

- Canonical URL: https://update.dsesecurity.com/updates/fence-the-former-postgresql-primary-before-accepting-failover/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-10-15T13:32:31+00:00
- Modified: 2026-10-15T13:36:15+00:00
- Last reviewed by DSE: 2026-10-15
- Resource type: Guide
- DSE priority: Information
- Topics: Business Continuity, IT
- Reading time: 2 minutes

## What you need to know

Make authority transfer and protection against a returning former primary part of failover acceptance.

## 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.

## Article

Make authority transfer and protection against a returning former primary part of failover acceptance.

## Source facts

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.

Source: [PostgreSQL 17 — Failover](https://www.postgresql.org/docs/17/warm-standby-failover.html).

## Applicability

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. 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.

## Verification

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.

## Official reference

[PostgreSQL 17 — Failover](https://www.postgresql.org/docs/17/warm-standby-failover.html). Reviewed October 15, 2026.

## Primary reference

- Name: PostgreSQL 17 — Failover
- Authority: www.postgresql.org
- URL: https://www.postgresql.org/docs/17/warm-standby-failover.html
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Fence the former PostgreSQL primary before accepting failover,” DSE Security, https://update.dsesecurity.com/updates/fence-the-former-postgresql-primary-before-accepting-failover/
Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/
Usage and citation policy: https://update.dsesecurity.com/usage/
Copyright © 2026 Detection Systems & Engineering. All rights reserved.