Re: Adding some error context for lock wait failures

2025-07-10 Thread Dilip Kumar
On Fri, Jul 11, 2025 at 9:34 AM Zhang Mingli wrote: > > On Jul 11, 2025 at 11:36 +0800, Dilip Kumar , wrote: > > > 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 obje

Re: Adding some error context for lock wait failures

2025-07-10 Thread Zhang Mingli
Hi, On Jul 11, 2025 at 11:36 +0800, Dilip Kumar , wrote: > > 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. May be conf

Re: Adding some error context for lock wait failures

2025-07-10 Thread Dilip Kumar
On Thu, Jul 10, 2025 at 10:36 PM Tom Lane 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

Re: Adding some error context for lock wait failures

2025-07-10 Thread Zhang Mingli
Hi, On Jul 11, 2025 at 10:53 +0800, Tom Lane , wrote: > Zhang Mingli writes: > > Do we need to rollback error_context_stack to the previous state if we > > enter the branch for PG_CATCH()? > > No. The PG_TRY mechanism itself deals with that: the next outer > level of PG_TRY will restore error_co

Re: Adding some error context for lock wait failures

2025-07-10 Thread Tom Lane
Zhang Mingli writes: > Do we need to rollback error_context_stack to the previous state if we enter > the branch for PG_CATCH()? No. The PG_TRY mechanism itself deals with that: the next outer level of PG_TRY will restore error_context_stack to what it had been. If this were not so, most other

Re: Adding some error context for lock wait failures

2025-07-10 Thread Zhang Mingli
Hi, On Jul 11, 2025 at 01:06 +0800, Tom Lane , 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 detai

Adding some error context for lock wait failures

2025-07-10 Thread Tom Lane
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