invalid_sql_statement_name prepared statement “…” does not exist — 26000

Symptoms

An EXECUTE/DEALLOCATE (or a protocol-level Bind/Execute) referenced a prepared statement name that the current session does not have. PostgreSQL raises SQLSTATE 26000 (invalid_sql_statement_name).

• Prepared statements are per-session and vanish on disconnect.
• Very common with poolers that switch the underlying connection.
• The named statement was never prepared on this connection.

What the server log shows

ERROR:  prepared statement "stmt1" does not exist

Why PostgreSQL raises this — what the manual says

the EXECUTE reference (Description):

“Since prepared statements only exist for the duration of a session, the prepared statement must have been created by a PREPARE statement executed earlier in the current session.”

Prepared statements live in the memory of the session that created them. If you execute against a different session (or after the statement was deallocated), the name cannot be found and PostgreSQL reports 26000.

Common causes

• A transaction-level pooler routing EXECUTE to a different backend than PREPARE.
• The session reconnected, discarding its prepared statements.
• DEALLOCATE (or DISCARD ALL) removed the statement.

How to fix it

1. With PgBouncer in transaction mode, disable server-side prepared statements or use protocol-level prepared-statement support.
2. Re-prepare the statement on the connection before executing.
3. Pin connections (session pooling) when relying on prepared statements.

Related & next steps

• SQLSTATE 26000 — Invalid SQL Statement Name (full reference)
• Message: prepared statement already exists
• Glossary: Connection pooling

Reference: PostgreSQL 18 — EXECUTE.