| From: | Sagar Shedge <sagar(dot)shedge92(at)gmail(dot)com> |
|---|---|
| To: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: [PATCH v1] Report specific wait events for libpq cancel requests |
| Date: | 2026-08-25 12:56:59 |
| Message-ID: | CAPhYifHHqh+AUYECrpm-m2L6UvRq3iRefX_UOuMTeNmYrJqNtQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Added CF entry for the same https://commitfest.postgresql.org/patch/7191/
On Tue, Aug 25, 2026 at 6:18 PM Sagar Shedge <sagar(dot)shedge92(at)gmail(dot)com>
wrote:
> Dear Hackers,
>
> libpqsrv_cancel() currently always reports the generic PG_WAIT_CLIENT
> wait event while waiting for a cancel request to be acknowledged by
> the remote server, no matter which caller invoked it. This makes it
> hard to tell from pg_stat_activity whether a backend is stuck waiting
> on a cancel ack versus any other generic client wait.
>
> Attached patch adds a wait_event_info parameter to libpqsrv_cancel(),
> so each caller can report a wait event specific to its own operation,
> following the same pattern already used for connection and
> query-result waits (e.g. PostgresFdwConnect, PostgresFdwGetResult).
> postgres_fdw now reports PostgresFdwCancel, and dblink now reports
> DblinkCancel, each allocated lazily via WaitEventExtensionNew() like
> their sibling wait events. Documentation for both new wait events is
> included.
>
> The new wait event is documented in postgres-fdw.sgml.
>
> --
> Sagar Dilip Shedge,
> Multigres Engineer, Supabase
>
>
--
Sagar Dilip Shedge,
Multigres Engineer, Supabase
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Sami Imseih | 2026-08-25 13:00:14 | Re: pg_stat_statements: a reset mid-query leaves an entry unnormalized forever |
| Previous Message | Shlok Kyal | 2026-08-25 12:51:01 | Re: Apply worker can pick an invalid index for REPLICA IDENTITY FULL lookups |