| From: | Dilip Kumar <dilipbalaut(at)gmail(dot)com> |
|---|---|
| To: | Zhang Mingli <zmlpostgres(at)gmail(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Steve Baldwin <steve(dot)baldwin(at)gmail(dot)com> |
| Subject: | Re: Adding some error context for lock wait failures |
| Date: | 2025-07-11 04:19:49 |
| Message-ID: | CAFiTN-vf2NTA=yaRdEBh1LZfxwRBYN1mDCBWAMckMzzq-W+DZw@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Jul 11, 2025 at 9:34 AM Zhang Mingli <zmlpostgres(at)gmail(dot)com> wrote:
>
> On Jul 11, 2025 at 11:36 +0800, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, 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 confused if there were tables with same names under different schemas.
If that's the only issue we can print schema qualified name, but I
think the problem is in error callback we just have lock tag
information which only have OIDs and we don't look up the
relcaches/sys table from the error path.
--
Regards,
Dilip Kumar
Google
| From | Date | Subject | |
|---|---|---|---|
| Next Message | jian he | 2025-07-11 05:53:52 | Re: SQL:2023 JSON simplified accessor support |
| Previous Message | Zhang Mingli | 2025-07-11 04:03:46 | Re: Adding some error context for lock wait failures |