Skip site navigation (1) Skip section navigation (2)

Re: Improving deadlock error messages

From: Neil Conway <neilc(at)samurai(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Improving deadlock error messages
Date: 2007-04-21 21:56:49
Message-ID: 1177192609.16415.107.camel@localhost.localdomain (view raw or flat)
Thread:
Lists: pgsql-hackers
On Sat, 2007-04-21 at 02:38 -0400, Tom Lane wrote:
> Maybe so, but you're going to be writing quite a lot of duplicative
> code, because the existing routines you might have been thinking of
> using (lsyscache.c etc) don't behave that way.

Right, I'm envisioning doing a conditional LockAcquire and then
heap_open() / heap_getnext() by hand. That will be relatively slow, but
code that emits a deadlock error message is almost by definition not
performance critical.

BTW, another alternative would be to set a global variable instructing
LockAcquire() to not block waiting for a lock; instead, it would
longjmp(), a la elog(ERROR). You could even construct something similar
to PG_TRY():

PG_COND_LOCK();
{
    /* do various things that might acquire lmgr locks */
}
PG_ACQUIRE_FAILED()
{
    /* failed to acquire an lmgr lock */
}
PG_END_COND_LOCK();

The risk would be leaving the LockAcquire() call site in an inconsistent
state when we longjmp(), but since DeadLockReport() is going to
ereport(ERROR) anyway, it might be sufficiently safe. This scheme does
seem a bit fragile, though...

-Neil



In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2007-04-21 23:21:10
Subject: Re: [HACKERS] parser dilemma
Previous:From: Gustavo ToniniDate: 2007-04-21 21:37:44
Subject: Re: Fragmentation project

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group