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
