SQLSTATE 42P05Severity lowLab verified

Incident brief

Duplicate prepared statement

Preparing a statement with a name that is already prepared in the session raises this error; prepared-statement names must be unique per session.

What lands in your log

ERROR: prepared statement "dup_ps" already exists

Reproduced on PostgreSQL 18.4Verified 2026-07-24 (isolated lab, PostgreSQL 18.4)Verified against PostgreSQL 18.4 in an isolated lab environment

In 10 seconds

What triggers it
PREPARE a statement under a given name.
Fix
Use a unique name, or DEALLOCATE the existing statement before re-preparing it.
Proof
Reproduced on PostgreSQL 18.4 → The reproduction prepares a name, then prepares it again: the second PREPARE raises SQLSTATE 42P05.

Fix

What to do right now

Application-level steps for this error.

  • Use a unique name, or DEALLOCATE the existing statement before re-preparing it.
  • In drivers and pools, let the driver manage prepared-statement names or DEALLOCATE ALL on connection reset.
Fix SQL
-- Prepare each statement name once per session.
PREPARE dup_ps AS SELECT 1;

Runbook to fix this

The runbook for this incident

Full step-by-step fixes for the condition behind this error: the diagnosis, the exact SQL, and output captured in the lab.

Connected

Everything this error touches

Every page this SQLSTATE connects to: the concept that explains it, the runbooks that fix it, the parameters you tune to prevent it, and the sibling errors it travels with. All real cross-references. Jump straight in, or open the full interactive map.

Open in the interactive map →

Verification

PG 18.4
Last verified
2026-07-24 (isolated lab, PostgreSQL 18.4)
Verification scope
Verified against PostgreSQL 18.4 in an isolated lab environment
Audit status
reviewed
ShareLinkedInX

Went further?

Pro unlocks the second lab proof

Free page stops the bleeding. Pro adds the operational test, SQLSTATE audit, and deeper evidence, same error, more certainty.

FollowSubstackLinkedInnew errors · lab notes · hiring loops