| From: | Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> |
|---|---|
| To: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Fix unsafe PlannedStmt access in pg_stat_statements |
| Date: | 2026-05-11 08:07:29 |
| Message-ID: | 2F91906A-F2B5-4A6B-9695-D136957D4545@gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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/
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Chao Li | 2026-05-11 08:11:41 | Re: Fix unsafe PlannedStmt access in pg_stat_statements |
| Previous Message | Michael Paquier | 2026-05-11 08:06:45 | Re: Refactor code around GUC default_toast_compression |