On Mar 24, 2008, at 6:21 PM, Tom Lane wrote:
> 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.
Something I always find myself wanting when debugging locking issues
is what's in pg_locks. Could we save that information somewhere when
we detect a deadlock? In a real table would be nice, but I'd settle
for just dumping it to a file somewhere. Or maybe into the logs.
--
Decibel!, aka Jim C. Nasby, Database Architect decibel@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828
