| From: | Sami Imseih <samimseih(at)gmail(dot)com> |
|---|---|
| To: | Julien Rouhaud <rjuju123(at)gmail(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Cleaning up PREPARE query strings? |
| Date: | 2026-01-18 16:16:16 |
| Message-ID: | CAA5RZ0sU-XUaGAATHhNZ-85u5h8SSbw0ykBPdBjOK-YXQkoy6g@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
>
> > ISTM that your proposal will actually use more memory because
> > pstate->p_sourcetext does not get free'd, but we must now allocate
> > space for a new "cleaned" query.
>
> I'm not sure that I understand. Sure we allocate a new temporary buffer
> for
> the cleaned up query string but this will be freed soon. The query string
> stored in the prepared statement will stay in memory as long as the prepare
> statement exist so this any cleanup can actually save a lot of memory.
>
My point is pstate->p_sourcetext doesn't get freed just because we're not
referencing it from CachedPlanSource in prepared_queries. Instead, with
multi-statement strings, prepared_queries now use a newly allocated string,
new_query, which will be around until DEALLOCATE.
```
+ tmp = palloc(rawstmt->stmt_len + 1);
+ strlcpy(tmp, cleaned, rawstmt->stmt_len + 1);
+
+ new_query = tmp;
```
So this patch always increases memory usage for multi-statement strings;
we have both the original multi-statement string and the cleaned up copy
around.
--
Sami Imseih
Amazon Web Services (AWS)
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Kirill Reshke | 2026-01-18 18:56:24 | Re: let ALTER TABLE DROP COLUMN drop whole-row referenced object |
| Previous Message | Filip Janus | 2026-01-18 15:50:24 | Re: Proposal: Adding compression of temporary files |