08007ERRORTier 1 — Safe✅ HIGH confidence

transaction resolution unknown

Category: Connection ExceptionVersions: All Postgres versions

🔴 Production Risk Error

Critical: silent duplicate writes if the original commit succeeded and a retry is issued without verifying state first.

What this means

SQLSTATE 08007 is raised when the connection breaks at exactly the point where Postgres was committing a transaction, leaving it unknown whether the commit succeeded or failed. This is the most dangerous connection error because the application cannot know the outcome without querying the database.

Why it happens

1Network failure or server crash precisely during the COMMIT flush to WAL
2Connection pool killing a connection at the moment of commit

How to reproduce

Connection fails mid-COMMIT during a payment or order write.

trigger — this will ERROR

ERROR: connection failure during transaction commit — transaction resolution unknown

Fix 1: Query the database to determine whether the transaction committed

Immediately after catching 08007.

fix

-- Check for presence of a known side-effect of the transaction:
SELECT COUNT(*) FROM orders WHERE order_id = :order_id;

Why this works

Reconnect on a fresh connection and check for business-observable evidence of the transaction. If present, the commit succeeded; do not retry. If absent, the commit failed; retry is safe.

Fix 2: Use idempotent operations with a client-generated idempotency key

When designing systems that must tolerate uncertain commits.

fix

INSERT INTO orders (order_id, ...) VALUES (:client_uuid, ...)
ON CONFLICT (order_id) DO NOTHING;

Why this works

A client-supplied UUID as the primary key makes the insert idempotent. Retrying after 08007 is safe because a duplicate insert is silently ignored.

What not to do

✗

Retry the transaction blindly after 08007

Why it's wrong: If the original transaction committed, a blind retry causes duplicate data (double charges, duplicate orders, etc.).

Dangerous variant

⚠️ Warning

08007 during financial or order transactions — check for duplicates before retrying

Sources

📚 Official docs: https://www.postgresql.org/docs/current/errcodes-appendix.html

🔧 Source ref: Class 08 — Connection Exception

Confidence assessment

✅ HIGH confidence

Standard SQLSTATE for uncertain commit resolution. Postgres raises this rarely but it represents a critical production risk when it occurs.