Alvaro Herrera <alvherre@commandprompt.com> writes:
> Gregory Stark wrote:
>> The axis on which I still see real room for improvement here is on the
>> description of the locks. It's awfully hard for a user to tell from the
>> deadlock message exactly what operation of the query was acquiring what lock
>> when it deadlocked.
> Are the involved queries not enough? Why? What would you like to
> have?
Greg's certainly got a point. Consider for example tuple-level locks
taken as a result of an FK check --- which one, and which rows are
involved? Or the case where the logged query is just "SELECT
some_huge_user_defined_function()" and you have no idea what part of the
function is triggering it. (The CONTEXT traceback will help here if the
backend running the function is the one that errors out, but not when
it's some other backend.)
I don't have any immediate ideas for improvement either, but we
certainly shouldn't consider this a totally solved problem.
regards, tom lane
