TransactionStateException
Exception thrown when the statement itself is fine and the transaction it arrived in is not.
The server rejects these before the statement is considered on its own merits, which is why they are not StatementException: nothing about the SQL is wrong, and the server sends no error position to point at. What is wrong is the state around it - a transaction an earlier error already doomed, one declared read-only, one open where the command forbids it, or none open where the command requires one.
25P02 is the one worth naming twice, because it is a consequence rather than a cause: after any error inside an explicit transaction PostgreSQL discards the work and rejects every further command until a ROLLBACK arrives. The failure to read is the first one; this one only says the session never left it.
The two class-25 timeouts, 25P03 and 25P04, are not here - they end the session rather than refuse a statement, and a session the server ended is SessionTerminatedException.
Parameters
The SQL state code returned by the database.
The original error message from the database server.
Constructors
Properties
Where this happened, innermost first, appended to by each layer as the exception unwinds. It is on the base class for the same reason queryContext is: adding to it is the only thing a frame can do to an exception without replacing it, and replacing one costs the type the caller catches on - a ConstraintViolationException restated as something else stops being the failure a retry looks for. A mapper walking a nested composite appends the attribute it was on, a transaction plan the step and parameter it was resolving. Rendered reversed, outermost first, so PATH: step 1 -> parameter 'name' -> map #1 reads from the plan down to the lambda.
The context of the query that resulted in this exception, if applicable.
The transaction state that refused the statement.
The raw error message received from the database, if applicable.