Re: Adding some error context for lock wait failures

Hi,

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