Re: Fix unsafe PlannedStmt access in pg_stat_statements

> On May 11, 2026, at 16:07, Chao Li <li(dot)evan(dot)chao(at)gmail(dot)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/