Re: [PATCH v1] Report specific wait events for libpq cancel requests

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

In response to

Browse pgsql-hackers by date

  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