Determine if an error is transient by its error code.

From: "Dominick O'Dierno" <odiernod(at)gmail(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Determine if an error is transient by its error code.
Date: 2017-03-20 02:26:12
Message-ID: CAD0baJ6wOgqFqkkmnOChe=S+A6=tUF95c2PpGxWC1W7EdCDH2Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello folks,

I'm trying to define a transient fault detection strategy for a client
application when calling a postgres database.

Essentially I want to determine by the error code if it is worth retrying
the call (transient) or if the error was due to a bad query or programmer
error, in which case don't retry.

Going through the codes as posted here
https://www.postgresql.org/docs/9.6/static/errcodes-appendix.html I had a
go at making a list of error codes which may be transient:

53000: insufficient_resources
53100: disk_full
53200: out_of_memory
53300: too_many_connections
53400: configuration_limit_exceeded
57000: operator_intervention
57014: query_canceled
57P01: admin_shutdown
57P02: crash_shutdown
57P03: cannot_connect_now
57P04: database_dropped
58000: system_error
58030: io_error

These next few I am not sure whether they should be treated as transient or
not, but I am guessing so

55P03: lock_not_available
55006: object_in_use
55000: object_not_in_prerequisite_state
08000: connection_exception
08003: connection_does_not_exist
08006: connection_failure
08001: sqlclient_unable_to_establish_sqlconnection
08004: sqlserver_rejected_establishment_of_sqlconnection
08007: transaction_resolution_unknown

Are there any codes listed above where retrying would actually not be
helpful?
Are there any codes that I did not include that I should have?

Thanks,

-Dominick

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2017-03-20 02:39:16 Re: Partition-wise join for join between (declaratively) partitioned tables
Previous Message Vaishnavi Prabakaran 2017-03-20 01:32:15 Re: PATCH: Batch/pipelining support for libpq