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
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
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
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
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
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
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