Re: Adding some error context for lock wait failures

Hi,

On Jul 11, 2025 at 01:06 +0800, 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.
>
> 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