PostgreSQL SQLSTATE Atlas

• 1: All SQLSTATE codes
• 2: SQLSTATE classes
• 3: Common codes
• 4: Topics
• 5: PostgreSQL versions
• 6: Guides
• 7: Coverage
• 8: Methodology
• 9: 00000 — successful_completion
• 10: 01000 — warning
• 11: 01003 — null_value_eliminated_in_set_function
• 12: 01004 — string_data_right_truncation
• 13: 01006 — privilege_not_revoked
• 14: 01007 — privilege_not_granted
• 15: 01008 — implicit_zero_bit_padding
• 16: 0100C — dynamic_result_sets_returned
• 17: 01P01 — deprecated_feature
• 18: 02000 — no_data
• 19: 02001 — no_additional_dynamic_result_sets_returned
• 20: 03000 — sql_statement_not_yet_complete
• 21: 08000 — connection_exception
• 22: 08001 — sqlclient_unable_to_establish_sqlconnection
• 23: 08003 — connection_does_not_exist
• 24: 08004 — sqlserver_rejected_establishment_of_sqlconnection
• 25: 08006 — connection_failure
• 26: 08007 — transaction_resolution_unknown
• 27: 08P01 — protocol_violation
• 28: 09000 — triggered_action_exception
• 29: 0A000 — feature_not_supported
• 30: 0B000 — invalid_transaction_initiation
• 31: 0F000 — locator_exception
• 32: 0F001 — invalid_locator_specification
• 33: 0L000 — invalid_grantor
• 34: 0LP01 — invalid_grant_operation
• 35: 0P000 — invalid_role_specification
• 36: 0Z000 — diagnostics_exception
• 37: 0Z002 — stacked_diagnostics_accessed_without_active_handler
• 38: 10608 — invalid_argument_for_xquery
• 39: 20000 — case_not_found
• 40: 21000 — cardinality_violation
• 41: 22000 — data_exception
• 42: 22001 — string_data_right_truncation
• 43: 22002 — null_value_no_indicator_parameter
• 44: 22003 — numeric_value_out_of_range
• 45: 22004 — null_value_not_allowed
• 46: 22005 — error_in_assignment
• 47: 22007 — invalid_datetime_format
• 48: 22008 — datetime_field_overflow
• 49: 22009 — invalid_time_zone_displacement_value
• 50: 2200B — escape_character_conflict
• 51: 2200C — invalid_use_of_escape_character
• 52: 2200D — invalid_escape_octet
• 53: 2200F — zero_length_character_string
• 54: 2200G — most_specific_type_mismatch
• 55: 2200H — sequence_generator_limit_exceeded
• 56: 2200L — not_an_xml_document
• 57: 2200M — invalid_xml_document
• 58: 2200N — invalid_xml_content
• 59: 2200S — invalid_xml_comment
• 60: 2200T — invalid_xml_processing_instruction
• 61: 22010 — invalid_indicator_parameter_value
• 62: 22011 — substring_error
• 63: 22012 — division_by_zero
• 64: 22013 — invalid_preceding_or_following_size
• 65: 22014 — invalid_argument_for_ntile_function
• 66: 22015 — interval_field_overflow
• 67: 22016 — invalid_argument_for_nth_value_function
• 68: 22018 — invalid_character_value_for_cast
• 69: 22019 — invalid_escape_character
• 70: 2201B — invalid_regular_expression
• 71: 2201E — invalid_argument_for_logarithm
• 72: 2201F — invalid_argument_for_power_function
• 73: 2201G — invalid_argument_for_width_bucket_function
• 74: 2201W — invalid_row_count_in_limit_clause
• 75: 2201X — invalid_row_count_in_result_offset_clause
• 76: 22021 — character_not_in_repertoire
• 77: 22022 — indicator_overflow
• 78: 22023 — invalid_parameter_value
• 79: 22024 — unterminated_c_string
• 80: 22025 — invalid_escape_sequence
• 81: 22026 — string_data_length_mismatch
• 82: 22027 — trim_error
• 83: 2202E — array_subscript_error
• 84: 2202G — invalid_tablesample_repeat
• 85: 2202H — invalid_tablesample_argument
• 86: 22030 — duplicate_json_object_key_value
• 87: 22031 — invalid_argument_for_sql_json_datetime_function
• 88: 22032 — invalid_json_text
• 89: 22033 — invalid_sql_json_subscript
• 90: 22034 — more_than_one_sql_json_item
• 91: 22035 — no_sql_json_item
• 92: 22036 — non_numeric_sql_json_item
• 93: 22037 — non_unique_keys_in_a_json_object
• 94: 22038 — singleton_sql_json_item_required
• 95: 22039 — sql_json_array_not_found
• 96: 2203A — sql_json_member_not_found
• 97: 2203B — sql_json_number_not_found
• 98: 2203C — sql_json_object_not_found
• 99: 2203D — too_many_json_array_elements
• 100: 2203E — too_many_json_object_members
• 101: 2203F — sql_json_scalar_required
• 102: 2203G — sql_json_item_cannot_be_cast_to_target_type
• 103: 22P01 — floating_point_exception
• 104: 22P02 — Invalid text representation
• 105: 22P03 — invalid_binary_representation
• 106: 22P04 — bad_copy_file_format
• 107: 22P05 — untranslatable_character
• 108: 22P06 — nonstandard_use_of_escape_character
• 109: 23000 — integrity_constraint_violation
• 110: 23001 — restrict_violation
• 111: 23502 — not_null_violation
• 112: 23503 — foreign_key_violation
• 113: 23505 — unique_violation
• 114: 23514 — check_violation
• 115: 23P01 — exclusion_violation
• 116: 24000 — invalid_cursor_state
• 117: 25000 — invalid_transaction_state
• 118: 25001 — active_sql_transaction
• 119: 25002 — branch_transaction_already_active
• 120: 25003 — inappropriate_access_mode_for_branch_transaction
• 121: 25004 — inappropriate_isolation_level_for_branch_transaction
• 122: 25005 — no_active_sql_transaction_for_branch_transaction
• 123: 25006 — read_only_sql_transaction
• 124: 25007 — schema_and_data_statement_mixing_not_supported
• 125: 25008 — held_cursor_requires_same_isolation_level
• 126: 25P01 — no_active_sql_transaction
• 127: 25P02 — in_failed_sql_transaction
• 128: 25P03 — idle_in_transaction_session_timeout
• 129: 25P04 — transaction_timeout
• 130: 26000 — invalid_sql_statement_name
• 131: 27000 — triggered_data_change_violation
• 132: 28000 — invalid_authorization_specification
• 133: 28P01 — invalid_password
• 134: 2B000 — dependent_privilege_descriptors_still_exist
• 135: 2BP01 — dependent_objects_still_exist
• 136: 2D000 — invalid_transaction_termination
• 137: 2F000 — sql_routine_exception
• 138: 2F002 — modifying_sql_data_not_permitted
• 139: 2F003 — prohibited_sql_statement_attempted
• 140: 2F004 — reading_sql_data_not_permitted
• 141: 2F005 — function_executed_no_return_statement
• 142: 34000 — invalid_cursor_name
• 143: 38000 — external_routine_exception
• 144: 38001 — containing_sql_not_permitted
• 145: 38002 — modifying_sql_data_not_permitted
• 146: 38003 — prohibited_sql_statement_attempted
• 147: 38004 — reading_sql_data_not_permitted
• 148: 39000 — external_routine_invocation_exception
• 149: 39001 — invalid_sqlstate_returned
• 150: 39004 — null_value_not_allowed
• 151: 39P01 — trigger_protocol_violated
• 152: 39P02 — srf_protocol_violated
• 153: 39P03 — event_trigger_protocol_violated
• 154: 3B000 — savepoint_exception
• 155: 3B001 — invalid_savepoint_specification
• 156: 3D000 — invalid_catalog_name
• 157: 3F000 — invalid_schema_name
• 158: 40000 — transaction_rollback
• 159: 40001 — serialization_failure
• 160: 40002 — transaction_integrity_constraint_violation
• 161: 40003 — statement_completion_unknown
• 162: 40P01 — deadlock_detected
• 163: 42000 — syntax_error_or_access_rule_violation
• 164: 42501 — insufficient_privilege
• 165: 42601 — syntax_error
• 166: 42602 — invalid_name
• 167: 42611 — invalid_column_definition
• 168: 42622 — name_too_long
• 169: 42701 — duplicate_column
• 170: 42702 — ambiguous_column
• 171: 42703 — undefined_column
• 172: 42704 — undefined_object
• 173: 42710 — Duplicate object
• 174: 42712 — Duplicate alias
• 175: 42723 — Duplicate function
• 176: 42725 — Ambiguous function
• 177: 42803 — Grouping error
• 178: 42804 — Datatype mismatch
• 179: 42809 — Wrong object type
• 180: 42830 — Invalid foreign key
• 181: 42846 — Cannot coerce
• 182: 42883 — Undefined function
• 183: 428C9 — Generated-always column assignment
• 184: 42939 — Reserved name
• 185: 42P01 — undefined_table
• 186: 42P02 — Undefined parameter
• 187: 42P03 — Duplicate cursor
• 188: 42P04 — Duplicate database
• 189: 42P05 — Duplicate prepared statement
• 190: 42P06 — Duplicate schema
• 191: 42P07 — Duplicate table or relation definition
• 192: 42P08 — Ambiguous parameter type
• 193: 42P09 — Ambiguous table alias
• 194: 42P10 — Invalid column reference
• 195: 42P11 — Invalid cursor definition
• 196: 42P12 — Invalid database definition
• 197: 42P13 — Invalid function definition
• 198: 42P14 — Invalid prepared statement definition
• 199: 42P15 — Invalid schema definition
• 200: 42P16 — Invalid table definition
• 201: 42P17 — Invalid object definition
• 202: 42P18 — Indeterminate datatype
• 203: 42P19 — Invalid recursion
• 204: 42P20 — Windowing error
• 205: 42P21 — Collation mismatch
• 206: 42P22 — Indeterminate collation
• 207: 44000 — with_check_option_violation
• 208: 53000 — insufficient_resources
• 209: 53100 — disk_full
• 210: 53200 — out_of_memory
• 211: 53300 — too_many_connections
• 212: 53400 — configuration_limit_exceeded
• 213: 54000 — program_limit_exceeded
• 214: 54001 — statement_too_complex
• 215: 54011 — too_many_columns
• 216: 54023 — too_many_arguments
• 217: 55000 — Object not in prerequisite state
• 218: 55006 — Object in use
• 219: 55P02 — cant_change_runtime_param
• 220: 55P03 — lock_not_available
• 221: 55P04 — unsafe_new_enum_value_usage
• 222: 57000 — operator_intervention
• 223: 57014 — query_canceled
• 224: 57P01 — admin_shutdown
• 225: 57P02 — crash_shutdown
• 226: 57P03 — cannot_connect_now
• 227: 57P04 — database_dropped
• 228: 57P05 — idle_session_timeout
• 229: 58000 — system_error
• 230: 58030 — io_error
• 231: 58P01 — undefined_file
• 232: 58P02 — duplicate_file
• 233: 58P03 — file_name_too_long
• 234: 72000 — snapshot_too_old
• 235: Class 00 — Successful Completion
• 236: Class 01 — Warning
• 237: Class 02 — No Data (this is also a warning class per the SQL standard)
• 238: Class 03 — SQL Statement Not Yet Complete
• 239: Class 08 — Connection Exception
• 240: Class 09 — Triggered Action Exception
• 241: Class 0A — Feature Not Supported
• 242: Class 0B — Invalid Transaction Initiation
• 243: Class 0F — Locator Exception
• 244: Class 0L — Invalid Grantor
• 245: Class 0P — Invalid Role Specification
• 246: Class 0Z — Diagnostics Exception
• 247: Class 10 — XQuery Error
• 248: Class 20 — Case Not Found
• 249: Class 21 — Cardinality Violation
• 250: Class 22 — Data Exception
• 251: Class 23 — Integrity Constraint Violation
• 252: Class 24 — Invalid Cursor State
• 253: Class 25 — Invalid Transaction State
• 254: Class 26 — Invalid SQL Statement Name
• 255: Class 27 — Triggered Data Change Violation
• 256: Class 28 — Invalid Authorization Specification
• 257: Class 2B — Dependent Privilege Descriptors Still Exist
• 258: Class 2D — Invalid Transaction Termination
• 259: Class 2F — SQL Routine Exception
• 260: Class 34 — Invalid Cursor Name
• 261: Class 38 — External Routine Exception
• 262: Class 39 — External Routine Invocation Exception
• 263: Class 3B — Savepoint Exception
• 264: Class 3D — Invalid Catalog Name
• 265: Class 3F — Invalid Schema Name
• 266: Class 40 — Transaction Rollback
• 267: Class 42 — Syntax Error or Access Rule Violation
• 268: Class 44 — WITH CHECK OPTION Violation
• 269: Class 53 — Insufficient Resources
• 270: Class 54 — Program Limit Exceeded
• 271: Class 55 — Object Not In Prerequisite State
• 272: Class 57 — Operator Intervention
• 273: Class 58 — System Error (errors external to PostgreSQL itself)
• 274: Class 72 — Snapshot Failure
• 275: Class F0 — Configuration File Error
• 276: Class HV — Foreign Data Wrapper Error (SQL/MED)
• 277: Class P0 — PL/pgSQL Error
• 278: Class XX — Internal Error
• 279: F0000 — config_file_error
• 280: F0001 — lock_file_exists
• 281: HV000 — fdw_error
• 282: HV001 — fdw_out_of_memory
• 283: HV002 — fdw_dynamic_parameter_value_needed
• 284: HV004 — fdw_invalid_data_type
• 285: HV005 — fdw_column_name_not_found
• 286: HV006 — fdw_invalid_data_type_descriptors
• 287: HV007 — fdw_invalid_column_name
• 288: HV008 — fdw_invalid_column_number
• 289: HV009 — fdw_invalid_use_of_null_pointer
• 290: HV00A — fdw_invalid_string_format
• 291: HV00B — fdw_invalid_handle
• 292: HV00C — fdw_invalid_option_index
• 293: HV00D — fdw_invalid_option_name
• 294: HV00J — fdw_option_name_not_found
• 295: HV00K — fdw_reply_handle
• 296: HV00L — fdw_unable_to_create_execution
• 297: HV00M — fdw_unable_to_create_reply
• 298: HV00N — fdw_unable_to_establish_connection
• 299: HV00P — fdw_no_schemas
• 300: HV00Q — fdw_schema_not_found
• 301: HV00R — fdw_table_not_found
• 302: HV010 — fdw_function_sequence_error
• 303: HV014 — fdw_too_many_handles
• 304: HV021 — fdw_inconsistent_descriptor_information
• 305: HV024 — fdw_invalid_attribute_value
• 306: HV090 — fdw_invalid_string_length_or_buffer_length
• 307: HV091 — fdw_invalid_descriptor_field_identifier
• 308: P0000 — plpgsql_error
• 309: P0001 — raise_exception
• 310: P0002 — no_data_found
• 311: P0003 — too_many_rows
• 312: P0004 — assert_failure
• 313: PostgreSQL 10.23 — formal
• 314: PostgreSQL 11.22 — formal
• 315: PostgreSQL 12.22 — formal
• 316: PostgreSQL 13.23 — formal
• 317: PostgreSQL 14.24 — formal
• 318: PostgreSQL 15.19 — formal
• 319: PostgreSQL 16.15 — formal
• 320: PostgreSQL 17.11 — formal
• 321: PostgreSQL 18.6 — formal
• 322: PostgreSQL 19beta3 — preview
• 323: PostgreSQL 9.0.23 — formal
• 324: PostgreSQL 9.1.24 — formal
• 325: PostgreSQL 9.2.24 — formal
• 326: PostgreSQL 9.3.25 — formal
• 327: PostgreSQL 9.4.26 — formal
• 328: PostgreSQL 9.5.25 — formal
• 329: PostgreSQL 9.6.24 — formal
• 330: XX000 — internal_error
• 331: XX001 — data_corrupted
• 332: XX002 — index_corrupted

1 - All SQLSTATE codes

Browse the complete SQLSTATE catalogue by class, version and content depth. Each code links to reviewed English and Chinese explanations. See the coverage page for current content and runtime coverage.

Read the methodology page for the identity and evidence contract.

2 - SQLSTATE classes

The class index groups codes by the first two SQLSTATE characters. A class describes a broad condition family; it does not prove that every member has the same severity, transaction aftermath, or retry behavior.

The generated member list links to one canonical page per code. A member’s class is directory identity; mechanism and recovery remain on the code page.

3 - Common codes

This is an editorial entry point for frequent diagnosis paths. It is not a measured ranking of production frequency; each row states the practical question the entry helps answer and preserves its review state.

4 - Topics

Topic indexes cover constraint conflicts, authentication and authorization, transaction retry, locks and timeouts, object resolution, and resource or system failures. Topics point to code pages; they do not create a second identity for a condition.

5 - PostgreSQL versions

The generated table distinguishes formal PostgreSQL releases from the latest preview snapshot. Presence means the definition was found in the locked source; it does not by itself prove a runtime path or an exact introduction release.

6 - Guides

Read the wire diagnostic

Start with the protocol message type. PostgreSQL sends an ErrorResponse for an error and a NoticeResponse for a notice; both carry identified fields terminated by a zero byte. The C field is the non-localized SQLSTATE, M is the primary message, and D/H are optional detail and hint. S can be localized; V is the non-localized severity when supplied. Schema (s), table (t), column (c), constraint (n), position (P), context (W), source file (F), line (L), and routine (R) are conditional fields: preserve them when present and do not infer missing fields. See the PostgreSQL 18 error and notice fields and message formats.

A directory class is only a classifier. Read the actual protocol severity and message type before deciding whether a command failed. A WARNING or NOTICE may arrive as a notice while the command completes; ERROR arrives as an error and normally changes explicit transaction state. A successful CommandComplete has a command tag and no ErrorResponse SQLSTATE. Keep the server version and operation beside the fields because one SQLSTATE can have several source paths.

Recover the right transaction boundary

Autocommit gives each statement its own transaction boundary. After a statement error, an otherwise usable connection can execute a later statement. In an explicit transaction, an unhandled ERROR leaves the transaction failed; PostgreSQL then rejects ordinary commands with 25P02 until rollback. 25P02 is a follow-on observation, not the first error. Use the ROLLBACK and SAVEPOINT references for the boundary you actually established.

If an already-existing savepoint surrounds one optional unit, use ROLLBACK TO SAVEPOINT name, then continue in the outer transaction or release the savepoint. Work before that savepoint remains. Without such a savepoint, ROLLBACK ends the failed transaction and a retry starts a new one. The accepted 25P02 case shows root 23505, subsequent 25P02, and recovery; 23505 evidence records the narrower savepoint boundary.

A PL/pgSQL EXCEPTION block is another narrow boundary. Changes made inside the block are rolled back before its handler runs, while earlier outer work remains. In the handler, SQLSTATE and SQLERRM identify the current exception; GET STACKED DIAGNOSTICS can retrieve RETURNED_SQLSTATE, message, detail, hint, context, and object fields. See error trapping, stacked diagnostics, and RAISE. Keep the handler around the smallest operation that can be classified safely; WHEN OTHERS should not discard the original fields.

Retry a complete unit only when its outcome is known

Retry is a business decision, not a property of a SQLSTATE class. For a transient serialization or deadlock error, retry the whole transaction from a fresh snapshot when the operation is safe. Do not replay only the last statement if earlier reads, writes, locks, notifications, or external calls formed one business unit. A transaction may have committed while the client timed out or lost its connection before receiving the result; completion can then be uncertain. Use an idempotency key, durable business key, or status query before repeating externally visible work.

For authorization failures, missing objects, and invalid data, first inspect and repair the permission, object, or input; then decide whether a corrected operation is safe to run. A warning that already completed the command should not trigger automatic replay. Preserve the first diagnostic and transaction state; log a later 25P02 as a consequence. Backoff and attempt limits control load, but cannot make a non-idempotent operation safe. A clear server-side timeout or cancellation is a failed operation; a lost connection before the client knows the outcome is a separate uncertain-completion case.

Correlate application and server logs

Record SQLSTATE, non-localized severity, primary message, detail, hint, object names, position/context, server version, backend PID when available, and client transaction state before formatting a human message. Add an application request or idempotency key and timestamp so the operation can be found in server logs. PID, session identifiers, and query ID are correlation aids, not replacements for protocol fields.

CSV and JSON server logs are structured but do not have the same shape as an ErrorResponse. PostgreSQL 18 documents csvlog columns including severity, SQLSTATE, message, detail, hint, context, query, source location, application name, backend type, and query ID. jsonlog is JSON and may omit null-valued fields; consumers should ignore future fields. Configure log_destination and logging_collector using the logging reference, then correlate by PID/session/request rather than assuming a CSV column or JSON key equals a protocol field.

PL/pgSQL and custom conditions

RAISE can report DEBUG, LOG, INFO, NOTICE, WARNING, or EXCEPTION; EXCEPTION normally aborts the current transaction. It can select a condition name or five-character SQLSTATE and set MESSAGE, DETAIL, HINT, SCHEMA, TABLE, COLUMN, DATATYPE, or CONSTRAINT with USING. PostgreSQL permits any five-character code made of digits and upper-case ASCII letters except 00000, including custom codes. A code ending in three zeroes is a category and can only be trapped by that category. See RAISE syntax.

A named handler matches its condition and documented aliases; a class handler is broader. WHEN OTHERS catches every error condition except QUERY_CANCELED and ASSERT_FAILURE; notice-level messages are not exceptions. A custom code raised by PL/pgSQL proves that deliberate report only, not natural emission by core, contrib, FDW, ECPG, or a driver.

What clients expose

The table pins each row to an inspected release or primary documentation. It does not claim that all six clients were runtime-tested here.

Named exception classes, constants, and wrappers are convenience mappings. Cross-client evidence remains the protocol SQLSTATE and fields; a client-side message or null SQLSTATE does not overwrite a confirmed server-log code. Existing psycopg 3.3.5/libpq 18.6 startup records with driver-null and server 28P01/53300 demonstrate this boundary for that stack only.

7 - Coverage

Coverage is reported separately for formal release definitions, preview snapshots, paired English and Chinese pages, editorial depth, source confirmation, and runtime cases. A generated page count is not a substitute for useful reference content.

• Formal definition snapshots: 16 displayed, 351 in the complete formal history; formal SQLSTATE union: 263.
• Preview definition snapshots: 1; preview union: 262, including 0 preview-only values.
• Bilingual page pairs: 263; complete English-to-Chinese revision bindings: 263.
• Content depth: full 82, reference 181, stub 0; editorial review: reviewed 263, pending 0.
• Selected runtime observations (unique code, summary, case): 181; passed 165, not applicable 16, failed 0, not run 0.
• Source usage (codes with at least one status; categories may overlap): definition only 222, source path confirmed 193, observed runtime 66, explicit unknown 183; unknown scopes are record counts: history 128, natural runtime 173, emitting path 12, other 8. History or natural-runtime uncertainty is not counted as an unknown emitting path. 6 aliases across 6 codes.
• Runtime observations are deduplicated by code, summary, and case_id; target record applicability (passed/not applicable) remains separate from each boundary assertion outcome.

8 - Methodology

Scope and frozen inputs

The atlas starts from PostgreSQL release definitions and separates directory identity, source implementation, official documentation, and local runtime observation. The locked manifest contains 351 formal tags, one PostgreSQL 19 Beta 3 preview, 19 definition blobs, a 263-code union, and 44 classes. The public display is a smaller matrix of 16 formal major snapshots (9.0–18) plus the preview; it is not the complete tag history. PostgreSQL 18.6 is fixed at REL_18_6 commit 724edf9bde9d356724ad384a2e196edc3c9f80f7, with definitions in src/backend/utils/errcodes.txt; PostgreSQL 19 Beta 3 is a separate preview at 3638289fb57bdabec00deda98ee9624a35f5d66a.

Formal history has an 18.4→18.6 tag gap. Pre-9 collection covers 191 tags from 7.0 through 8.4.22: 7.4–8.4 have definition files, while 7.0–7.3 have candidate-path probes. Missing old paths are source gaps, not proof of absence. known_present_by is a presence boundary; exact introduction or removal is recorded only when adjacent source evidence proves both sides.

Evidence states

Each claim names the source path and fixed release, tag, or commit that supports it. definition_only establishes catalogue identity and history, not a reporting path. source_path_confirmed identifies a concrete call or implementation context. observed_runtime requires a real run record, applicable passed assertions, and the actual SQLSTATE; source scans and skipped cases cannot promote themselves to runtime coverage. unknown records an unresolved scope, not absolute absence.

Lexical source candidates are read in C context before adoption. The private call scan is bounded research input, not reader-facing proof. Core, contrib, extension, custom-function, ECPG, driver, and remote-server paths remain distinct. An ECPG program or client can reuse a PostgreSQL-defined code, and an FDW or driver can forward a remote code, without proving that server core reports that code in the same operation. Conversely, a core source path does not prove every wrapper or client exposes every field.

Official PO text can confirm a fixed commit, message domain, and placeholder boundary, but not Chinese runtime output. Locale, driver behavior, server version, and message delivery must be observed separately. Internal messages and dynamic fields retain their source conditions; translated or formatted strings are never stable protocol keys.

Runtime and recovery boundaries

Runtime observations use isolated versioned targets and preserve enough environment and structured result to identify the asserted case and version. A passed observation covers that case and version only. not_run, not_applicable, source-only, and driver-null-SQLSTATE cases remain explicit. Startup authentication/resource failures are outside a SQL transaction; a server log can carry SQLSTATE even when a startup exception has no driver SQLSTATE. In an explicit transaction, a root error and later 25P02 are separate observations; a savepoint handler, PL/pgSQL exception block, and whole-transaction retry have different scopes.

A deliberate PL/pgSQL custom code can demonstrate protocol delivery and handler matching, but is not evidence that core, contrib, FDW, ECPG, or a driver naturally reports the same code. Such observations are labeled as deliberate behavior rather than natural subsystem behavior.

Translation and maintenance

English is the source page. Each Chinese pair preserves anchors, SQLSTATE identity, facts, citations, diagnostic fields, and recovery boundaries in natural Chinese. Chinese front matter stores the English page’s deterministic UTF-8 SHA-256 over normalized {title, description, body}; changing English title, description, or prose makes the pair stale until translated and refreshed. Generated fact blocks are delimited and may be refreshed from data/errcodes; author prose and evidence are maintained separately.

A useful maintenance change updates fixed source citations, evidence state, and both language pages together. It does not infer a runtime mechanism from a renamed condition, old PO entry, generic API signature, or client wrapper. Published catalogue and evidence views are presentation layers over accepted records; they are not evidence creation.

Primary records

The public version matrix, catalogue, evidence index, and runtime case index expose accepted projections. Maintainers use reports/CATALOGUE.md, reports/SOURCE-SCAN.md, reports/RUNTIME-BOUNDARIES.md, and reports/RUNTIME.md for the underlying records; these report paths are repository locations, not public page links. The manifest lock is sources/manifest.lock.json (SHA-256 1727a275f336988ff96b4f9990a4ca253080f73fc5d316e7def165c8cf3708a8); the pre-9 lock is sources/pre9-manifest.lock.json (SHA-256 77bedf102d109972e91ff1b61841d78a38da7c7c049e428782392761a4ce7cd6).

9 - 00000 — successful_completion

00000 — successful_completion

At a glance

00000 is the successful-completion SQLSTATE. PostgreSQL’s error machinery selects it by default for messages below WARNING when no more specific code is set; a successful command does not need an error message.

Meaning

The default SQLSTATE is selected by errstart from the message level; elog.c sets ERRCODE_SUCCESSFUL_COMPLETION for levels below WARNING. This is a source-level default in the error machinery, not an application error mechanism or a promise that a normal command carries an ErrorResponse.

Messages and diagnostics

Command completion is normally represented by a successful result and command tag; it does not carry an ErrorResponse SQLSTATE. In the fixed elog path, 00000 is initialized only when no more-specific code is supplied and the message level is below WARNING. Preserve a diagnostic’s actual protocol message type and severity alongside the code: 00000 is not an ERROR default and does not turn a successful result into an ErrorResponse.

Diagnosis

Check the client result status and command tag first. If a client reports 00000 alongside a failed status or an ErrorResponse, inspect the producer and client API’s status handling rather than treating it as normal successful completion or searching for an assumed error detail.

Response

Handle a successful command result as completion. For a NoticeResponse carrying 00000, retain the notice separately from the command result; investigate client status handling only when those signals conflict. Do not retry a successful command merely because this code is present.

Versions

The locked catalogue has 00000 from 9.0.23 through 18.6 and 19 Beta 3, with known_present_by 7.4. The fixed 18.6 elog.c path shows the default assignment for levels below WARNING; it is not a runtime test of every client protocol.

Related

01000 is the warning class; 02000 is no-data, a different condition; P0002 is PL/pgSQL no_data_found.

Sources

• errcodes.txt — definition, SHA-256 6e8de346643ba84aa3c9c6a73360acfc7b2dfb89162c06c08ce9bf5bcd5bbcba.
• elog.c — fixed path, SHA-256 766d30a426ba1d9597657bd46fb890da3e37e4ae53a83d1245bf082ed9433c33.
• Structured evidence — fixed sources, message groups, and runtime boundary.

10 - 01000 — warning

At a glance

01000 is the generic warning condition in Class 01, Warning. It is a directory classification, not a description of one particular subsystem or message. PostgreSQL’s source directory explicitly says not to use this class for failure conditions.

The five-character code must be read together with the protocol severity and the complete diagnostic. In an ErrorResponse or NoticeResponse, S is the possibly localized severity and V is the nonlocalized severity. A message can therefore arrive as WARNING, NOTICE, INFO, or another notice level while its SQLSTATE is still 01000 when the emitting code supplied that code explicitly.

For the common default path, PostgreSQL maps ereport(WARNING, ...) to 01000, levels at or above ERROR to XX000, and lower levels to 00000. An explicit errcode() can override that default. This is why the directory’s W marker is useful, but it does not by itself prove that the wire message was an actual WARNING.

The representative generic_warning_boundary probe passed on PostgreSQL 18.6 and 10.21. It uses PL/pgSQL RAISE WARNING to verify the default 01000 dispatch, receives an actual WARNING notice, and keeps the autocommit connection usable. It does not exercise the asynchronous NOTIFY, hstore, XID, or MultiXact warning paths.

The locked catalogue has a pre-9.0 presence observation at PostgreSQL 7.4 and records 01000 in every listed formal snapshot from 9.0.23 through 18.6 plus the 19 Beta 3 preview. The pre-9.0 source scan covers 7.4 through 8.4.22; candidate source gaps remain for 7.0 through 7.3. This is a known presence boundary, not an exact introduction version.

Meaning and trigger paths

The locked 18.6 definition is 01000 W ERRCODE_WARNING warning under Class 01. The default severity mapping is in elog.c: an ERROR or higher level starts with ERRCODE_INTERNAL_ERROR, a WARNING level starts with ERRCODE_WARNING, and lower levels start with ERRCODE_SUCCESSFUL_COMPLETION. The later error construction can replace that initial code.

Several real paths use the generic warning code:

• The asynchronous notification queue reports NOTIFY queue is %.0f%% full. When an old listener transaction is identified, it adds a detail naming the PID and a hint to end that transaction. This is a queue pressure warning, not an array, privilege, or constraint failure.
• Transaction ID and MultiXact wraparound protection reports that a database must be vacuumed within a remaining number of transactions or MultiXact IDs. Its hints point to a database-wide VACUUM and to old prepared transactions or stale replication slots.
• The SPI cleanup path explicitly supplies ERRCODE_WARNING for a non-empty SPI stack and points to missing SPI_finish calls. Here the code is explicit even though the severity is also WARNING.

These source-confirmed examples show why the message, detail, hint, source context, and operation are more actionable than 01000 alone. Other Class 01 conditions, such as 01003 or 0100C, have their own SQLSTATEs and should not be collapsed into this generic code.

Messages and diagnostics

The executable representative is the registry entry generic_warning_boundary:

DO $$ BEGIN RAISE WARNING 'calibration warning'; END $$;
SELECT 1;

Both PostgreSQL 18.6 and 10.21 delivered the warning through the notice channel with SQLSTATE 01000, severity WARNING, and primary message calibration warning. The follow-up SELECT 1 succeeded and the connection was IDLE. This is a real RAISE WARNING dispatch check; it is not runtime evidence for the separate NOTIFY queue, hstore compatibility, transaction-ID, or MultiXact paths listed above.

Diagnosis

Capture C/sqlstate, S, V, M, D, and H from the driver or protocol, together with the statement, database, backend PID, and timestamp. In a client library with a notice handler, record notices as well as exceptions: a warning-level NoticeResponse can be delivered without raising a statement exception. Keep the original localized message and the nonlocalized severity when available.

Check SHOW client_min_messages and SHOW log_min_messages when a message is missing from the client or server log. Those settings control delivery and logging thresholds; they do not change the underlying cause. For a repeated warning, search logs by SQLSTATE and the stable message template, then inspect the named subsystem:

• NOTIFY queue ... full calls for long-lived listener transactions and the PID in DETAIL.
• XID or MultiXact vacuum warnings call for transaction age, prepared transactions, and replication slots before wraparound protection becomes an actual failure.
• A non-empty SPI stack points toward extension or server-side SPI lifecycle handling.

Do not infer a transaction abort, a broken connection, or data corruption from 01000 alone. The representative warning left its session usable, but a later statement may fail for an independent reason, and a function or client operation may impose its own control flow.

Response

Treat the message’s subsystem and hint as the repair target. End or repair the transaction that is holding a notification queue or old transaction horizon; perform the indicated database-wide maintenance after checking replication slots and prepared transactions; or fix the extension’s SPI ownership. Preserve the original diagnostic while investigating.

An actual WARNING or lower-level notice does not by itself put an explicit transaction into the aborted state, and it normally leaves the connection able to continue. Verify the next command and transaction status instead of assuming either outcome from the code. If a subsequent ERROR occurs, handle that error’s SQLSTATE and recover with ROLLBACK or a suitable savepoint according to that error’s contract.

Raising client_min_messages or log_min_messages can reduce noise, but it does not repair the queue, transaction horizon, or SPI lifecycle. Use suppression only after the underlying signal has been understood.

Versions

The catalogue records 01000 in the locked 7.4–8.4.22 pre-9.0 formal sources and in all formal catalogue snapshots from 9.0.23 through 18.6, plus 19 Beta 3. The same-tag REL8_1_4 errcodes.sgml table already lists the older 1000 spelling with condition name warning, so this condition-name observation is confirmed by 8.1.4. Candidate source gaps remain for 7.0–7.3, so the 7.4 observation is a presence boundary rather than an exact introduction version. The 18.6 source snapshot is fixed at commit 724edf9bde9d356724ad384a2e196edc3c9f80f7.

The protocol severity fields and the client_min_messages/log_min_messages controls are documented for PostgreSQL 18. The representative source paths above are 18.6 observations; their presence does not claim that every message template is unchanged in every older release.

Related

00000 — successful_completion is the default low-level completion code. 01003 — null_value_eliminated_in_set_function and 0100C — dynamic_result_sets_returned are more specific Class 01 conditions. XX000 — internal_error is the default code for an ERROR without an explicit code; it is not interchangeable with a warning. 25P02 — in_failed_sql_transaction describes a later command rejected because an earlier error aborted the transaction, not a consequence that should be assigned to every 01000 message.

Sources

The structured evidence for this page is recorded in the public evidence JSON. The source and documentation records use fixed PostgreSQL commit 724edf9bde9d356724ad384a2e196edc3c9f80f7; runtime records retain the exact snippet registry and run IDs for the passed probe.

• src.errcodes.18.6 — errcodes.txt
• src.elog.18.6 — elog.c
• src.async.18.6 — async.c
• src.varsup.18.6 and src.multixact.18.6 — transaction horizon warning paths
• src.spi.18.6 — explicit warning code in the SPI cleanup path
• doc.protocol.18 and doc.logging.18 — Error and Notice Message Fields and When to Log

11 - 01003 — null_value_eliminated_in_set_function

01003 — null_value_eliminated_in_set_function

At a glance

01003 is a warning-category condition whose name describes null elimination in a set function. No resolved 18.6 core/contrib report group was found, so no PostgreSQL aggregate, message, or client severity path is confirmed here.

Meaning

The definition names null elimination in a set function, but the fixed source scan does not locate a PostgreSQL emitter. The producer may be a server extension, client, or another implementation.

Messages and diagnostics

No resolved 18.6 message variant was found. Preserve the original warning text, statement, aggregate or set-function context, and the server/client source that emitted it.

Diagnosis

Identify the producer before changing the query: the SQLSTATE alone does not establish which aggregate or driver behavior occurred. Check whether the producer reported a warning, notice, or only a diagnostic code, and distinguish null elimination from a query returning no rows.

Response

If the identified implementation documents a setting or expression change, apply that targeted change and verify the result. Do not suppress or retry every warning generically.

Versions

01003 is present from the locked 9.0.23 snapshot through 18.6 and 19 Beta 3, with known_present_by 7.4. This establishes definition presence, not a confirmed current server emitter.

Related

01004 is string truncation warning; 02000 is no-data; 00000 is successful completion.

Sources

• errcodes.txt — definition, SHA-256 6e8de346643ba84aa3c9c6a73360acfc7b2dfb89162c06c08ce9bf5bcd5bbcba.
• Structured evidence — fixed sources, message groups, and runtime boundary.

12 - 01004 — string_data_right_truncation

01004 — string_data_right_truncation

At a glance

01004 names right truncation reported as a warning condition. No resolved 18.6 core/contrib report group was found, so this page does not assign a particular cast, encoding path, client, or message.

Meaning

The definition names right truncation as a warning condition. Without a resolved call group, the accepted truncation behavior, data preservation, and producer remain unknown.

Messages and diagnostics

No resolved 18.6 message variant was found. Preserve the exact value/column context, declared and received lengths when available, encoding, producer version, and complete diagnostics.

Diagnosis

Locate the source that emitted the code and compare its length and encoding rules with the value being transferred. Distinguish a warning that preserves a truncated value from an error that rejects the statement; the SQLSTATE alone does not decide that behavior.

Response

Use the producer’s supported length or encoding adjustment and verify whether data was intentionally truncated. Do not silently retry the same input when information may already have been lost.

Versions

01004 is present from the locked 9.0.23 snapshot through 18.6 and 19 Beta 3, with known_present_by 7.4. The available evidence establishes catalogue presence, not a current core emission path.

Related

01003 concerns null elimination; 01008 concerns zero-bit padding; 22001 is a separate error-category string truncation condition.

Sources

• errcodes.txt — definition, SHA-256 6e8de346643ba84aa3c9c6a73360acfc7b2dfb89162c06c08ce9bf5bcd5bbcba.
• Structured evidence — fixed sources, message groups, and runtime boundary.

13 - 01006 — privilege_not_revoked

01006 — privilege_not_revoked

At a glance

01006 has confirmed PostgreSQL 18.6 WARNING paths in src/backend/catalog/aclchk.c for REVOKE. It reports a partial or empty privilege change; the command can complete while sending the warning.

Meaning

The confirmed 18.6 implementation is the ACL command path for REVOKE. It distinguishes no privilege revoked from not all privileges revoked and uses column-specific and object-specific templates.

Messages and diagnostics

The fixed 18.6 paths use these primary templates: no privileges could be revoked for column "%s" of relation "%s", no privileges could be revoked for "%s", not all privileges could be revoked for column "%s" of relation "%s", and not all privileges could be revoked for "%s". They have no detail or hint in the resolved groups.

Diagnosis

Record whether the target was a column or an object and the resolved relation/object name. In the fixed aclchk.c function, this_privileges is the requested set intersected with the effective grantor’s available grant options. The REVOKE warning is none when that mask is zero, and partial when !all_privs and the mask differs from the request; this warning branch does not inspect the grantee’s old ACL. Inspect the effective grantor, grant options, requested privileges, and then the resulting ACL separately. A WARNING is distinct from an ERROR that aborts the command.

Response

Treat the command result and warning separately. If the intended access change was not achieved, correct the target role/object or requested privilege and verify the resulting ACL; repeating REVOKE without changing the mismatch may produce the same warning.

Versions

01006 is present from the locked 9.0.23 snapshot through 18.6 and 19 Beta 3, with known_present_by 8.0.0. The fixed 18.6 warning paths are in aclchk.c; this is not a claim that every historical version used identical wording.

Related

01007 is the corresponding privilege-not-granted warning; 42501 is an error-category privilege failure; 01000 is the warning class.

Sources

• errcodes.txt — definition, SHA-256 6e8de346643ba84aa3c9c6a73360acfc7b2dfb89162c06c08ce9bf5bcd5bbcba.
• aclchk.c — fixed path, SHA-256 9700258318959b47c42edb423418fb511dd3a008023e732f601eecf4c80868f8.
• Structured evidence — fixed sources, message groups, and runtime boundary.

14 - 01007 — privilege_not_granted

01007 — privilege_not_granted

At a glance

01007 has confirmed PostgreSQL 18.6 WARNING paths in src/backend/catalog/aclchk.c for GRANT. It reports an empty or partial grant and does not by itself mean the GRANT statement failed as an error.

Meaning

The confirmed 18.6 implementation is the ACL command path for GRANT. It distinguishes no privilege granted from not all privileges granted and uses column-specific and object-specific templates.

Messages and diagnostics

The fixed 18.6 paths use no privileges were granted for column "%s" of relation "%s", no privileges were granted for "%s", not all privileges were granted for column "%s" of relation "%s", and not all privileges were granted for "%s". The resolved groups have no detail or hint.

Diagnosis

Record whether the target was a column or object and the exact relation/object name. In the fixed aclchk.c function, this_privileges is the requested set intersected with the effective grantor’s available grant options. The GRANT warning is none when that mask is zero, and partial when !all_privs and the mask differs from the request; this warning branch does not inspect the grantee’s old ACL. Inspect the effective grantor, grant options, requested privileges, and then the resulting ACL separately. Distinguish the partial WARNING from an error-category permission failure.

Response

Check the resulting ACL and correct the role, target, privilege, or grant option identified by the operation. Reissuing unchanged GRANT is useful only after the privilege mismatch has been understood.

Versions

01007 is present from the locked 9.0.23 snapshot through 18.6 and 19 Beta 3, with known_present_by 8.0.0. The fixed 18.6 paths establish current source wording and severity, not identical historical text.

Related

01006 is the privilege-not-revoked warning; 42501 is a permission error; 01000 is the warning class.

Sources

• errcodes.txt — definition, SHA-256 6e8de346643ba84aa3c9c6a73360acfc7b2dfb89162c06c08ce9bf5bcd5bbcba.
• aclchk.c — fixed path, SHA-256 9700258318959b47c42edb423418fb511dd3a008023e732f601eecf4c80868f8.
• Structured evidence — fixed sources, message groups, and runtime boundary.

15 - 01008 — implicit_zero_bit_padding

01008 — implicit_zero_bit_padding

At a glance

01008 names a warning-category condition for implicit zero-bit padding. No resolved 18.6 core/contrib report group was found, so no specific bit-string conversion or message is confirmed.

Meaning

The definition names implicit zero-bit padding as a warning condition. The fixed source scan does not locate the conversion or interface that would produce it.

Messages and diagnostics

No resolved 18.6 message variant was found. Preserve the producer, source and destination bit-string types, declared lengths, and complete diagnostic.

Diagnosis

Locate the actual type-conversion or driver path and compare its padding rule with the declared bit length. Do not infer padding from an ordinary string truncation or from a query that returns no rows.

Response

Use the producer’s explicit bit length or conversion form when padding is unintended, and verify the resulting value. Do not treat a warning code as proof that a statement was rolled back.

Versions

01008 is present from the locked 9.0.23 snapshot through 18.6 and 19 Beta 3, with known_present_by 7.4. The available evidence establishes definition presence only.

Related

01004 concerns string truncation; 01003 concerns null elimination; 22021 is an encoding error category.

Sources

• errcodes.txt — definition, SHA-256 6e8de346643ba84aa3c9c6a73360acfc7b2dfb89162c06c08ce9bf5bcd5bbcba.
• Structured evidence — fixed sources, message groups, and runtime boundary.

16 - 0100C — dynamic_result_sets_returned

0100C — dynamic_result_sets_returned

At a glance

0100C names a warning-category dynamic-result-set condition. No resolved 18.6 core/contrib report group was found, so no server-side producer, result-set count, or message is confirmed.

Meaning

The definition names dynamic result sets returned as a warning condition. The fixed source scan does not identify the producer or the result-set protocol.

Messages and diagnostics

No resolved 18.6 message variant was found. Preserve the producing routine or interface, result-set count/order, client API, and complete warning or notice diagnostics.

Diagnosis

Identify whether the producer is a procedural or client interface that supports dynamic result sets. Do not treat multiple command results from an ordinary SQL batch as this condition without source or protocol evidence.

Response

Consume or declare the result sets according to the identified interface contract, or adjust that contract deliberately. A generic transaction retry does not address result-set handling.

Versions

0100C is present from the locked 9.0.23 snapshot through 18.6 and 19 Beta 3, with known_present_by 7.4. This is catalogue evidence, not a confirmed 18.6 core emission path.

Related

02001 names no additional dynamic result sets; 01000 is the warning class; 00000 is successful completion.

Sources

• errcodes.txt — definition, SHA-256 6e8de346643ba84aa3c9c6a73360acfc7b2dfb89162c06c08ce9bf5bcd5bbcba.
• Structured evidence — fixed sources, message groups, and runtime boundary.

17 - 01P01 — deprecated_feature

01P01 — deprecated_feature

At a glance

PostgreSQL 18.6 emits 01P01 at WARNING severity when a password-setting operation produces or preserves an MD5 verifier. This is a deprecation notice attached to a command that can still proceed, not a generic failure code for every old feature.

Meaning

The confirmed 18.6 implementation is the password-setting path in src/backend/libpq/crypt.c; it warns when the resulting verifier is MD5. The trigger is the final stored verifier form, such as plaintext input under password_encryption = 'md5' or an already md5... verifier supplied as input; it is not the pg_hba.conf authentication method, and an existing SCRAM verifier is not by itself this warning.

Messages and diagnostics

The fixed path reports setting an MD5-encrypted password; detail: MD5 password support is deprecated and will be removed in a future release of PostgreSQL.; hint: Refer to the PostgreSQL documentation for details about migrating to another password type.

Diagnosis

Inspect the password-setting session’s SHOW password_encryption, whether the input is plaintext or an existing md5... verifier, and the final role verifier when permissions allow. Keep the complete warning because the detail and hint state the affected method and migration direction. Do not use the pg_hba.conf authentication method as the trigger, and do not infer that an existing SCRAM verifier caused this warning.

Response

Migrate the affected role to SCRAM by following the official Password Authentication guidance; for plaintext input, set password_encryption to scram-sha-256 before resetting the password, then verify client compatibility. Do not reuse an old MD5 verifier as the migration step. The warning itself does not call for retrying the password-setting command unchanged.

Versions

01P01 is present from the locked 9.0.23 snapshot through 18.6 and 19 Beta 3, with known_present_by 8.0.0. The fixed MD5 path and wording are confirmed for 18.6; other deprecated features or older wording require their own source evidence.

Related

01000 is the warning class; 28P01 is an invalid-password error; 00000 is successful completion.

Sources

• errcodes.txt — definition, SHA-256 6e8de346643ba84aa3c9c6a73360acfc7b2dfb89162c06c08ce9bf5bcd5bbcba.
• crypt.c — fixed path, SHA-256 d0c7579210827dbaec466f1c064a3d1ea2f7f7bfbf8b40b2e79fb4769cb406a9.
• Structured evidence — fixed sources, message groups, and runtime boundary.

18 - 02000 — no_data

02000 — no_data

At a glance

02000 has confirmed 18.6 DEBUG1/DEBUG2 paths in contrib/amcheck/verify_nbtree.c for internal index-check conditions. The three groups detailed below are each DEBUG1; they are not the same as a normal query returning zero rows and are not a generic client error.

Meaning

The confirmed 18.6 implementation is in contrib/amcheck/verify_nbtree.c, where index consistency diagnostics use ERRCODE_NO_DATA at DEBUG1 or DEBUG2. This is an internal diagnostic use, not ordinary SELECT no-row semantics. The authored evidence expands three representative groups; other source paths are outside that selected message set.

Messages and diagnostics

The selected fixed groups are:

• DEBUG1, internal errmsg_internal: harmless fast root mismatch in index "%s", with internal detail Fast root block %u (level %u) differs from true root block %u (level %u). The source labels this condition harmless.
• DEBUG1, internal errmsg_internal: block %u of index "%s" concurrently deleted. This branch has no detail or hint in the resolved group.
• DEBUG1, ordinary errmsg/errdetail/errhint: index uniqueness can not be checked for index tid=(%u,%u) in index "%s", with detail It doesn't have visible heap tids and key is equal to the tid=(%u,%u)%s (points to heap tid=(%u,%u)). and hint VACUUM the table and repeat the check. The VACUUM hint belongs to this group only.

Diagnosis

If this code comes from amcheck, identify the check, index, block/TID context and server log severity. Treat a fast-root mismatch as the source labels it: a harmless diagnostic requiring context, not automatic corruption repair. For a concurrently deleted block, correlate the concurrent operation or snapshot and rerun only after the relevant activity has settled. For the uniqueness-uncheckable group, inspect the named index and follow its specific VACUUM hint before repeating the check. For application no-row handling, inspect the command result or procedural condition actually returned; PL/pgSQL NO_DATA_FOUND is P0002, not a blanket synonym for 02000.

Response

Apply the branch-specific guidance: do not turn the harmless fast-root diagnostic into an automatic repair; investigate concurrent state for a concurrent deletion; and use VACUUM before repeating the check only when the uniqueness-uncheckable group supplies that hint. Do not require maintenance for every DEBUG finding, and do not add a no-row exception or retry to ordinary SELECT code solely because the SQLSTATE class is 02.

Versions

02000 is present from the locked 9.0.23 snapshot through 18.6 and 19 Beta 3, with known_present_by 7.4. The fixed 18.6 evidence covers the amcheck DEBUG paths; other producers need separate source evidence.

Related

P0002 is PL/pgSQL no_data_found; 02001 concerns additional dynamic result sets; 00000 is successful completion.

Sources

• errcodes.txt — definition, SHA-256 6e8de346643ba84aa3c9c6a73360acfc7b2dfb89162c06c08ce9bf5bcd5bbcba.
• verify_nbtree.c — fixed path, SHA-256 a59ae7540a990e5a70e8eb9cedbcad7c62e3e86b1ad426142c8931ee188b752d.
• Structured evidence — fixed sources, message groups, and runtime boundary.

19 - 02001 — no_additional_dynamic_result_sets_returned

02001 — no_additional_dynamic_result_sets_returned

At a glance