Hi,
On Jul 11, 2025 at 01:06 +0800, Tom Lane <[email protected]>, 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.
>
> Thoughts?
>
> regards, tom lane
>
> [1]
> https://www.postgresql.org/message-id/CAKE1AiY17RgcKCFba1N6Sz6SjHqSqvq%2BcfKWBfyKFEjT-L%2Bqkg%40mail.gmail.com
````
}
PG_CATCH();
{
/* In this path, awaitedLock remains set until LockErrorCleanup */
/* reset ps display to remove the suffix */
set_ps_display_remove_suffix();
/* and propagate the error */
PG_RE_THROW();
}
PG_END_TRY();
/*
* We no longer want LockErrorCleanup to do anything.
*/
awaitedLock = NULL;
/* reset ps display to remove the suffix */
set_ps_display_remove_suffix();
error_context_stack = waiterrcontext.previous;
```
Do we need to rollback error_context_stack to the previous state if we enter
the branch for PG_CATCH()?
--
Zhang Mingli
HashData
