Re: Adding some error context for lock wait failures
От | Dilip Kumar |
---|---|
Тема | Re: Adding some error context for lock wait failures |
Дата | |
Msg-id | CAFiTN-s9-fCV=3Gz6=EQZ6vn_oMXTY2ZDPOghTjgTN3r3pM3eA@mail.gmail.com обсуждение исходный текст |
Ответ на | Adding some error context for lock wait failures (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Adding some error context for lock wait failures
|
Список | pgsql-hackers |
On Thu, Jul 10, 2025 at 10:36 PM Tom Lane <tgl@sss.pgh.pa.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
В списке pgsql-hackers по дате отправления: