Simon Riggs <si...@2ndquadrant.com> wrote: > We don't have a retryable SQLSTATE, so perhaps we should document > that serialization_failure and deadlock_detected are both > retryable error conditions. As the above implies HS can throw some > errors that are non-retyable, so we use ERRCODE_ADMIN_SHUTDOWN. There is one SQLSTATE (40001 - serialization_failure) to indicate that the transaction failed due to conflicts with concurrent transactions. This is supposed to be used when there was no problem with the transaction itself, were it to be run when nothing else is running and the environment isn't failing. (For example, it isn't the right code to use if you fail because your network connection is broken or you're running out of disk space.) In my view it is a mistake *not* to use it whenever concurrent transactions cause failure; we can always use different error message text, details, and hints to differentiate between the particular ways in which concurrent transactions caused the failure. The advantage of consistently using the standard value for this is that there is software which recognizes this and automatically retries the transaction from the beginning in a manner which is transparent to the users and the application code. Our users never see anything but a delay when hitting this; it's effectively the same as blocking, with no application programmer effort needed. Having a separate deadlock_detected SQLSTATE is arguably a bug. (In fact, I have argued that; but haven't persuaded the community of it.) Coming up with yet another SQLSTATE to indicate that there's nothing wrong with the transaction except its timing in relation to other transactions would, in my view, compound the error. That said, our shop is resourceful enough (in more than one sense) to overcome this if need be. I just don't see why the community would choose to create barriers which cause failures for software which would otherwise Just Work, and the corresponding programming burden on shops using PostgreSQL to keep a list of "nothing really wrong with the transaction, you can probably just reschedule it" SQLSTATE values for the product. -Kevin
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers