Tatsuo Ishii <is...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
