Re: [HACKERS] ERRCODE_T_R_DEADLOCK_DETECTED

2015-03-19 Thread Tatsuo Ishii
>> I think the solution for this is assigning a unique id to each >> message. This is already done in some commercial databases. They are >> pretty usefull for tech supports. > > We already have file and line number recorded. Problem with it is, the line number (and sometimes the file name) chan

Re: [HACKERS] ERRCODE_T_R_DEADLOCK_DETECTED

2015-03-19 Thread Tom Lane
Tatsuo Ishii writes: >> 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. > I think the solution for this is assigning a unique id to each > message. This is already done in

Re: [HACKERS] ERRCODE_T_R_DEADLOCK_DETECTED

2015-03-19 Thread Tatsuo Ishii
>> 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 >

Re: [HACKERS] ERRCODE_T_R_DEADLOCK_DETECTED

2015-03-19 Thread Andres Freund
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 i

Re: [HACKERS] ERRCODE_T_R_DEADLOCK_DETECTED

2015-03-19 Thread Tatsuo Ishii
> 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

Re: [HACKERS] ERRCODE_T_R_DEADLOCK_DETECTED

2015-03-19 Thread Andres Freund
On 2015-03-19 12:50:09 +, Kevin Grittner wrote: > For me the big question is whether software written to retry a > transaction from the beginning when it gets this SQLSTATE would be > doing something dumb to retry transactions (perhaps after a brief > delay) for the conflict with recovery. If

Re: [HACKERS] ERRCODE_T_R_DEADLOCK_DETECTED

2015-03-19 Thread Kevin Grittner
Tatsuo Ishii wrote: > ereport(ERROR, > (errcode(ERRCODE_T_R_DEADLOCK_DETECTED), > errmsg("canceling statement due to conflict with recovery"), > errdetail("User transaction caused buffer deadlock with recovery."))); > > ereport(ERROR, > (errcode(E

[HACKERS] ERRCODE_T_R_DEADLOCK_DETECTED

2015-03-18 Thread Tatsuo Ishii
The error code is used in two places: ereport(ERROR, (errcode(ERRCODE_T_R_DEADLOCK_DETECTED), errmsg("canceling statement due to conflict with recovery"), errdetail("User transaction caused buffer deadlock with recovery.")));