Thread: ERRCODE_T_R_DEADLOCK_DETECTED
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.")));
ereport(ERROR, (errcode(ERRCODE_T_R_DEADLOCK_DETECTED), errmsg("deadlock detected"),
errdetail_internal("%s",clientbuf.data), errdetail_log("%s", logbuf.data), errhint("See server log for
querydetails.")));
The latter is a normal deadlock and can be obseved by stats because
pgstat_report_deadlock() is called.
The former is using the same error code but the meaning is pretty
different and users might be confused IMO.
I am not sure sharing the same error code is the best idea here.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
Tatsuo Ishii <ishii@postgresql.org> 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(ERRCODE_T_R_DEADLOCK_DETECTED),
> errmsg("deadlock detected"),
> errdetail_internal("%s", clientbuf.data),
> errdetail_log("%s", logbuf.data),
> errhint("See server log for query details.")));
>
> The latter is a normal deadlock and can be obseved by stats
> because pgstat_report_deadlock() is called.
>
> The former is using the same error code but the meaning is pretty
> different and users might be confused IMO.
>
> I am not sure sharing the same error code is the best idea here.
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.
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 using the same automated
recovery techniques is sane, then IMO it makes sense to use the
same SQLSTATE.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On 2015-03-19 12:50:09 +0000, 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 using the same automated > recovery techniques is sane, then IMO it makes sense to use the > same SQLSTATE. Yes, it imo makes sense to use the same techniques. In both cases you need to keep enough state to give up at some point; the combination of running transactions might make the likelihood of succeeding too low. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
> 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. Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese:http://www.sraoss.co.jp
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
>> 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. 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. Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese:http://www.sraoss.co.jp
Tatsuo Ishii <ishii@postgresql.org> 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 some commercial databases. They are
> pretty usefull for tech supports.
We already have file and line number recorded.
regards, tom lane
>> 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) change with version to version. Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese:http://www.sraoss.co.jp