Fix unsafe PlannedStmt access in pg_stat_statements

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/

Responses

Browse pgsql-hackers by date

  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