From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Cc: | Steve Baldwin <steve(dot)baldwin(at)gmail(dot)com> |
Subject: | Adding some error context for lock wait failures |
Date: | 2025-07-10 17:05:54 |
Message-ID: | 1602369.1752167154@sss.pgh.pa.us |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
Thoughts?
regards, tom lane
Attachment | Content-Type | Size |
---|---|---|
v1-provide-errcontext-in-WaitOnLock.patch | text/x-diff | 2.7 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Jacob Champion | 2025-07-10 17:12:05 | Re: Explicitly enable meson features in CI |
Previous Message | Srirama Kucherlapati | 2025-07-10 16:55:39 | RE: Buildfarm setup for AIX |