Horton

Re: Fix unsafe PlannedStmt access in pg_stat_statements

Chao Li <li.evan.chao@gmail.com>

View thread
From: Chao Li <li.evan.chao@gmail.com>
To: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2026-05-11T08:11:41Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. pg_stat_statements: Set PlannedStmt to NULL after nested utility execution

  2. pg_stat_statements: Fix potential use-after-free of PlannedStmt

  3. pg_stat_statements: Add counters for generic and custom plans

Attachments


> On May 11, 2026, at 16:07, Chao Li <li.evan.chao@gmail.com> wrote:
> 
> Hi,
> 
> I spotted this small issue while working on [1].
> 
> In pgss_ProcessUtility(), there is this comment:
> ```
> /*
> * CAUTION: do not access the *pstmt data structure again below here.
> * If it was a ROLLBACK or similar, that data structure may have been
> * freed.  We must copy everything we still need into local variables,
> * which we did above.
> *
> * For the same reason, we can't risk restoring pstmt->queryId to its
> * former value, which'd otherwise be a good idea.
> */
> ```
> 
> However, commit 3357471cf9f5e470dfed0c7919bcf31c7efaf2b9 added a new access to pstmt after that point:
> ```
> pgss_store(queryString,
>   saved_queryId,
>   saved_stmt_location,
>   saved_stmt_len,
>   PGSS_EXEC,
>   INSTR_TIME_GET_MILLISEC(duration),
>   rows,
>   &bufusage,
>   &walusage,
>   NULL,
>   NULL,
>   0,
>   0,
>   pstmt->planOrigin);
> ```
> 
> The attached patch fixes this by saving pstmt->planOrigin, following the same pattern already used for queryId, stmt_location, and stmt_len.
> 
> [1] https://www.postgresql.org/message-id/8ED8C22D-54CD-4EC4-B53C-D39F935FA83D%40gmail.com
> 
> Best regards,
> --
> Chao Li (Evan)
> HighGo Software Co., Ltd.
> https://www.highgo.com/
> 

Oops! Forgot the attachment.

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/