| From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
|---|---|
| To: | Tatsuo Ishii <ishii(at)postgresql(dot)org> |
| Cc: | kgrittn(at)ymail(dot)com, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: ERRCODE_T_R_DEADLOCK_DETECTED |
| Date: | 2015-03-19 14:33:54 |
| Message-ID: | 20150319143354.GG9495@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2015-03-19 23:31:21 +0900, Tatsuo Ishii wrote:
> > That SQLSTATE value is intended to be used where the transaction
> > has failed because it was run concurrently with some other
> > transaction, rather than before or after it; and it is intended to
> > suggest that the transaction may succeed if run after the competing
> > transaction has completed. If those apply, it seems like the right
> > SQLSTATE. A user can certainly distinguish between the conditions
> > by looking at the error messages.
>
> It is sad for users the only way to distinguish the conditions is by
> looking at the error messages. They want to know the root of the
> problem.
Sure. It's always a balance. If you go to the extreme of your argument
every possible error gets one individual error code. But then error
handling gets too complex.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2015-03-19 14:35:05 | Re: GSoC 2015: Extra Jsonb functionality |
| Previous Message | Tatsuo Ishii | 2015-03-19 14:31:21 | Re: ERRCODE_T_R_DEADLOCK_DETECTED |