> On May 11, 2026, at 16:07, Chao Li <[email protected]> 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/
v1-0001-Fix-unsafe-PlannedStmt-access-in-pg_stat_statemen.patch
Description: Binary data
