26000 — invalid_sql_statement_name
26000 — invalid_sql_statement_name
At a glance
26000 means that PostgreSQL was asked to use a named prepared statement that does not exist in the current backend session. It is a session-resource lookup failure, so first check session affinity and statement lifecycle before changing the SQL text.
| Field | Value |
|---|---|
| SQLSTATE | 26000 |
| Condition | invalid_sql_statement_name |
| Status | active |
| Known present by | 7.4 |
| Locked snapshots | 9.0.23, 9.1.24, 9.2.24, 9.3.25, 9.4.26, 9.5.25, 9.6.24, 10.23, 11.22, 12.22, 13.23, 14.24, 15.19, 16.15, 17.11, 18.6, 19beta3 |
| Macros | ERRCODE_INVALID_SQL_STATEMENT_NAME, ERRCODE_UNDEFINED_PSTATEMENT |
| Aliases | ERRCODE_UNDEFINED_PSTATEMENT |
Meaning
PREPARE registers a named statement in one PostgreSQL session. EXECUTE and DEALLOCATE resolve that name in the same session; a pool checkout can silently move the next command to another backend. The core prepare.c path reports the dynamic name with prepared statement "%s" does not exist. The fixed extended-query path in postgres.c separately reports unnamed prepared statement does not exist when the unnamed statement is absent.
Diagnosis
Read the driver exception’s SQLSTATE and primary message, then log the backend PID or an equivalent connection identity around PREPARE and EXECUTE. On that same connection, pg_prepared_statements can show whether the named entry exists; querying it on a different pooled connection is not evidence about the failing session. Distinguish a deallocation, a connection replacement, and an unnamed statement path from a malformed PREPARE statement.
Response
If the operation is inside an explicit transaction, roll back the failed block before issuing more commands. Recreate the statement on the session that will execute it, and keep the statement definition and parameter types under the same application or pool checkout. A missing statement has not itself applied the intended operation, but the application should still use its normal request identity and side-effect checks before repeating a larger workflow.
Messages
The fixed core templates include prepared statement "%s" does not exist from prepare.c and unnamed prepared statement does not exist from the extended-query path in postgres.c. The selected case reports source_file = prepare.c and source_function = FetchPreparedStatement; only the named template has a server-side name substitution. Do not parse either message as a stable error string; branch on SQLSTATE and structured diagnostics.
Representative case
The runner reads this sequence from verify/cases/26000/snippets.json (SHA-256 b9fdbb48371e0d9902cb9e055ececc4878c38422773a8a1571651d9952809032) and keeps every statement on one connection. The complete executable record is the public case export, with structured evidence.
statement_name is a page-level placeholder. The runner substitutes a unique identifier, deallocates it, asserts 26000 and IDLE, then repeats the registry’s same three statements—PREPARE, EXECUTE, and DEALLOCATE—to repair the session. The recovery sequence is therefore: PREPARE the named statement again, EXECUTE it on that same connection, and DEALLOCATE it when the checkout is finished; these are the existing prepare, execute, and deallocate registry statements, not a second SQL definition.
The selected runner case observed 26000 on PostgreSQL 18.6 and 10.21. It deallocated a named statement, observed the dynamic missing-name diagnostic with the connection IDLE, then recreated and executed the statement on that same session.
Versions
The locked catalogue reports this condition from the early historical boundary through the current formal snapshots. The fixed 18.6 source has both named and unnamed prepared-statement paths; the runtime comparison covers one named path on 18.6 and 10.21. The message wording and source line can vary by release, while the SQLSTATE identity remains 26000 in the selected targets.
Related
34000 invalid cursor name and 25P02 failed transaction are useful when a pool/session boundary or surrounding transaction is involved.
Sources
src.errcodes.18.6(SHA-2566e8de346643ba84aa3c9c6a73360acfc7b2dfb89162c06c08ce9bf5bcd5bbcba)src.prepare.18.6(SHA-256e37fbd5f7618e5554561d9293d8c3af7cf3190c62c5c6bbceb3fe8b97be17956)src.postgres.18.6(SHA-2569fb62275b1badf94d01ab351337b60410cd9b3ab1fe63fa9f23d6d2185a21061)PREPARE documentation· local call scansrc.calls.REL_18_6(SHA-2569ee8a0e81d8f0825c5c1ae45583439859a26e602bdd4ce2f2a62aa278867ccbf)