Re: Patch: show relation and tuple infos of a lock to acquire - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Patch: show relation and tuple infos of a lock to acquire
Date
Msg-id CA+TgmoZiwUSn0DBWvYoP-198woNiVKKLHHXEZSmuDTX+Mx8isA@mail.gmail.com
Whole thread Raw
In response to Re: Patch: show relation and tuple infos of a lock to acquire  (Greg Stark <stark@mit.edu>)
List pgsql-hackers
On Tue, Mar 18, 2014 at 11:59 AM, Greg Stark <stark@mit.edu> wrote:
> On Tue, Mar 18, 2014 at 3:42 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:
>> The message for exclusive lock on tuple print the database information.
>
> It is true that it is possible to have a deadlock or lock chains that
> involves locks on other databases.
> In this example the table "test" is not in the database that just
> logged the deadlock.
>
> STATEMENT:  create role test;
> ERROR:  deadlock detected
> DETAIL:  Process 8968 waits for ShareLock on transaction 1067; blocked
> by process 8973.
>         Process 8973 waits for ShareLock on transaction 1064; blocked
> by process 8971.
>         Process 8971 waits for ShareLock on transaction 1062; blocked
> by process 8968.
>         Process 8968: create role test;
>         Process 8973: insert into test values (2);
>         Process 8971: create role test2;

This is a good point, but I think it's acceptable to leave out the
database name as Tom proposes.  The context message applies to what
the current backend was doing when the message got printed, and that's
always relative to the current database.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Portability issues in shm_mq
Next
From: Robert Haas
Date:
Subject: Re: Patch: show relation and tuple infos of a lock to acquire