# Set replica identity before publishing PostgreSQL updates and deletes

> Check row-identification readiness before accepting a publication that must carry updates and deletes.

- Canonical URL: https://update.dsesecurity.com/updates/set-replica-identity-before-publishing-postgresql-updates-and-deletes/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-10-15T13:32:33+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

Check row-identification readiness before accepting a publication that must carry updates and deletes.

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

## Article

Check row-identification readiness before accepting a publication that must carry updates and deletes.

## Source facts

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.

Source: [PostgreSQL 17 — Publication](https://www.postgresql.org/docs/17/logical-replication-publication.html).

## Applicability

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

## Verification

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.

## Official reference

[PostgreSQL 17 — Publication](https://www.postgresql.org/docs/17/logical-replication-publication.html). Reviewed October 15, 2026.

## Primary reference

- Name: PostgreSQL 17 — Publication
- Authority: www.postgresql.org
- URL: https://www.postgresql.org/docs/17/logical-replication-publication.html
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Set replica identity before publishing PostgreSQL updates and deletes,” DSE Security, https://update.dsesecurity.com/updates/set-replica-identity-before-publishing-postgresql-updates-and-deletes/
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.