From: | Dilip Kumar <dilipbalaut(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org, Steve Baldwin <steve(dot)baldwin(at)gmail(dot)com> |
Subject: | Re: Adding some error context for lock wait failures |
Date: | 2025-07-11 03:35:48 |
Message-ID: | CAFiTN-s9-fCV=3Gz6=EQZ6vn_oMXTY2ZDPOghTjgTN3r3pM3eA@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Jul 10, 2025 at 10:36 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> I noted a complaint [1] about how hard it is to debug unforeseen
> lock-timeout failures: we give no details about what we were
> waiting for. It's not hard to improve that situation, at least
> to the extent of printing numeric locktag details similar to what
> you get in deadlock reports. (It'd be nice to give object names,
> but just as with deadlocks, incurring any additional lock
> acquisitions here seems too scary.) The attached patch will
> produce reports like
>
> regression=# begin;
> BEGIN
> regression=*# lock table tenk1;
> ^CCancel request sent
> ERROR: canceling statement due to user request
> CONTEXT: waiting for AccessExclusiveLock on relation 77382 of database 77348
> regression=!# abort;
> ROLLBACK
> regression=# set lock_timeout TO '1s';
> SET
> regression=# begin;
> BEGIN
> regression=*# lock table tenk1;
> ERROR: canceling statement due to lock timeout
> CONTEXT: waiting for AccessExclusiveLock on relation 77382 of database 77348
>
> and then the user can manually look up the object's identity.
>
This seems to be quite useful to me, initially I thought if we can
print the relation and database name then this could be even better
but it might be a bad idea to fetch the object name while we are in
error callback. And anyway deadlock error is also reported in the
same format so this makes sense.
--
Regards,
Dilip Kumar
Google
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2025-07-11 03:38:38 | Re: A recent message added to pg_upgade |
Previous Message | Zhang Mingli | 2025-07-11 03:32:50 | Re: Adding some error context for lock wait failures |