Re: pg_stat_statements stores WITH HOLD cursor query with literals

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Gaurav Singh <gaurav(dot)singh(at)yugabyte(dot)com>
Cc: Sami Imseih <samimseih(dot)pg(at)gmail(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: pg_stat_statements stores WITH HOLD cursor query with literals
Date: 2026-10-23 05:19:32
Message-ID: atruZFUdH40HVUJh@paquier.xyz
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Thu, Oct 22, 2026 at 12:09:56PM +0900, Michael Paquier wrote:
> We have a similar concept for ExplainState with its extension_state
> indexed by GetExplainExtensionId() based on an extension name.
> Perhaps we should do something similar for QueryDesc? That would take
> care of the conflicting states across extensions at least, giving
> extensions way to store in the QueryDesc what they want. Here, that's
> the nesting_level that you want to track *only* in PGSS and have no
> other extensions meddle with it.

This was itching me, so I have looked at what it would look like,
finishing with the attached set of two patches:
- One to introduce a backend-side facility to give for extensions a
way to plug in custom data into QueryDesc.
- The second patch is a refactored v2, that makes use of the new
infra.

That feels rather neat. This facility could be extended to other
things, like auto_explain perhaps?
--
Michael

Attachment Content-Type Size
v3-0001-Add-custom-extension-states-to-QueryDesc.patch text/plain 6.5 KB
v3-0002-pg_stat_statements-Fix-toplevel-tracking-across-n.patch text/plain 9.0 KB

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Prashant Kumar 2026-10-23 05:59:39 Re: BUG #19743: pgcrypto crypt(): sha-crypt rounds= silently wraps modulo 2^32
Previous Message Andrey Rachitskiy 2026-10-23 04:49:29 Re: BUG #19752: GROUP BY on a constant and a cast to a length-limited array type crashes the server while planning